Forum

The IEEE 802.11g committee members may have had something in mind, but it didn't make it out of committee and into the standard. The standard is mute. What hath the WLAN chip and device driver vendors wrought regarding this feature?

Oh no, my man. There is something different from the standard. Look closely.

Peter,

Upon reading your example of the 3 BSSs again and looking at the 802.11g document, I am starting to think the whole concept of the protection ripple idea is false. Here's why:

You quoted the standard as saying that an AP will enable protection if it sees that a nearby AP has non-ERP traffic. Criss also correctly stated that there is nothing in the standard specifying that the Use Protection subfield will *require* that protection be enabled in nearby APs.

That leads me to believe that in your example of 3 BSSs, the 3rd BSS would never enable protection. BSS1 enables protection because an 802.11b station associates. BSS2 enables protection because it sees the Non-ERP Present subfield set to 1. BSS3 would *not* enable protection at all because BSS2 would be sending Beacons with Use Protection = 1 and Non-ERP Present = 0.

What I'm saying here is that the Non-ERP Present subfield appears to do something that Gene and I didn't even recognize: it prevents the "Protection Ripple" from ever happening beyond one BSS. In an enterprise full of APs, a single 802.11b association would cause the APs immediately in the area to enable the protection mechanism, but having the two different subfields makes it so that the protection mechanism doesn't "ripple" out beyond that immediate area.

I could be wrong in all of this, of course. I've never tested a scenario like you mentioned, i.e, I've never setup 3 APs where the middle AP (AP2) can hear Beacons from both other APs but the APs on the end (AP1 and AP3) cannot hear Beacons from each other. Unfortunately I don't have a clean Wi-Fi area large enough to test something like this. If anyone ever has tested it, though, let me know.

As far as our original point, it still stands. There is a distinct behavioral difference in stations associated to a BSS with Non-ERP Present = 0 and Non-ERP Present = 1. This subtle difference *will* cause a noticable difference in the maximum throughput of the network.

Ben,
I actually did know that protection wouldn't extend beyond a second BSS, but credit goes to Devin, as I read his paper a while back.

This is such a great question. A big bright light bulb came on for me when Ben and I were discussing it. All credit goes to him. :)

Ben that is the exact point I was trying to make. My example was presuming we did not have the Non-ERP present subfield and showing the problem that would occur, however as we do have the subfield the 3rd BSS would never enable protection (subject to vendor implementation).

I was just trying to show the problem that would occur if you tried to combine the two subfields in to one value (hence justifying its existence in Beacons) and No wireless networks don?¡é?€??t work like that, thankfully. (I?¡é?€??m sorry my explanation does not seam to have been very clear)

I hope this post makes sense it is 15 minuets past midnight here in the UK so I?¡é?€??m going leave it there for tonight.

Peter,

No problem. That was just a mistake on my part, then. I read the whitepaper a while back but I must have missed the point that it is the Non-ERP Present field that enables co-channel protection, not the Use Protection field.

There is still the lingering question of the purpose of the Non-ERP Present field as it relates to station behavior. There is a noticable change there, trust me. I am curious to see if anyone sees what that change in station behavior is.

Ben

Are you talking about a change in the STAs behaviour that is above and beyond the use of protection mechanism?

Yep!

Hi:

While we are waiting to hear from Ben....

The following document has been referenced several times in this thread:
http://www.cwnp.com/learning_center/search_details.php?doc_id=l7w2

I think this document, titled "Protection Ripple in ERP 802.11 WLANs" and dated June 2004, accurately records the observed behavior of some WLAN equipment but inaccurately explains how that behavior relates to the IEEE 802.11 standard. I urge those who have relied on it for their understanding of ERP protection mechanisms to reexamine the matter and come to better conclusions.

For example the two summary bullets at the bottom of page two are half truth, half fantasy. Paraphrasing:

Bullet 1)
"If a NonERP station associates to an ERP AP the ERP AP will enable the NonERP_Present bit in its own beacons." This is required by the standard.

"This enables protection mechanisms in its BSS." This is false. Setting the Use_Protection bit orders that all stations in the BSS use protection mechanisms.

Bullet 2)
"If an ERP AP hears a beacon from a NonERP BSS, it will enable the NonERP_Present bit in its own beacons." This is suggested but not required by the standard. Apparently many vendors have taken up the suggestion.

"This enables protection mechanisms in its BSS." This is false. Setting the Use_Protection bit orders that all stations in the BSS use protection mechanisms.

A better explanation of the observed product behavior reported in the paper is this: There are several situations where an ERP BSS will set BOTH the NonERP_Present and Use_Protection bits in its beacons, the foremost being the association of a nonERP station. It has been observed that a second ERP BSS hearing the first beacons sets the Use_Protection bit but not the NonERP_Present bit in its beacons. It has been observed that a third ERP BSS hearing the second beacons is unaffected. As a consequence of the Use_Protection bit being set, protection mechanisms become required in the first two ERP BSSs but not the third. The behavior of the second BSS in setting the Use_Protection bit is not required by the standard but may be a smart vendor implementation.

Lastly the suggestion in the paper to hide the SSID is lame.

I hope this helps. Thanks. /criss

Criss,

Great post! I feel you have put in a very simple way what i was hoping would be the logical concussion from one of my earlier posts. I'm not sure i used the right way of explaining it or picked the right choice of words. Your explanation also ties up with the behaviour i have observed when analysing similar scenarios.

Thanks
Peter