What is the purpose of the "Non-ERP Present" subfield in the ERP Information Element? This field is present in all 802.11g Beacon frames.
The Non-ERP Present subfield shall be set to 1 when a Non-ERP STA (A station which only supports Clause 15 or Clause 18 rates) associates with the BSS. The 802.11g standard also provides us with these other examples of when the Non-ERP Present subfield may get set:
1) A Non-ERP infrastructure or independent BSS is overlapping (a Non-ERP BSS may be detected by the reception of a Beacon when the supported rates contain only Clause 15 or Clause 18 rates)
2) In an IBSS, if a Beacon frame is received from one of the IBSS participants where the supported rate set contains only Clause 15 or Clause 18 rates.
3) A management frame (excluding a Probe Request) is received where the supported rate set includes only Clause 15 or Clause 18 rates
Your answer would even make Criss proud! :-)
I have a whitepaper that covers this topic at: http://www.cwnp.com/learning_center/search_details.php?doc_id=l7w2
Great answer on what happens. Now I would like to know, why does the beacon include that field?
Why do I feel I know where these questions are leading?
If you read Devinator?¡é?€??s white paper, I would hope the question of why would be answered. The ?¡é?€??Non-ERP Present?¡é?€?? is set to 1 when a Non-ERP STA is associated with the BSS. The Non-ERP Present frame triggers protection within the BSS. This field in Beacons instructs other nearby APs to enable the ?¡é?€??Use Protection?¡é?€?? subfield.
If this line of questions is leading to the ?¡é?€??Why do you need the ?¡é?€??Non-ERP Present?¡é?€?? subfield, surely we only need to have the ?¡é?€??Use Protection?¡é?€?? subfield??¡é?€?? question, then you need to attend one of my courses. :)
You need to remember that the two sub fields have different jobs to do.
The ?¡é?€??Non-ERP Present?¡é?€?? Sub field indicates that a Non-ERP Station is associated with the BSS and triggers protection within the BSS. It also informs other nearby APs to enable protection.
The ?¡é?€??Use Protection?¡é?€?? subfield informs STA?¡é?€??s within a BSS to uses protection mechanism either RTS/CTS or CTS-to-Self.
Now think about what would happen if both of these jobs where achieved by just one field. It might to begin with seem like that would work fine.
However one example of a problem which may exists with this would come when disabling protection mechanism. In fact it may never be disabled.
Lets say we just used the ?¡é?€??Use Protection?¡é?€?? subfield to do both jobs and we have BSS#1 which has a Non-ERP STA associated with it. The protection ripple has happed and now BSS#2 (Who can hear BSS#1?¡é?€??s Beacons) and BSS#3 (who can hear BSS#2?¡é?€??s Beacons) have the ?¡é?€??Use Protection?¡é?€?? subfield set. Next the Non-ERP STA leaves BSS#1 and goes home. BSS#1?¡é?€??s AP sends out a beacon with the ?¡é?€??Use Protection?¡é?€?? sub field turned off. This beacon is recognised by the AP of BSS#2 and it turns protection off, However before it next transmits a Beacon it hears the Beacon from the AP in BSS#3 which has the ?¡é?€??Use Protection?¡é?€?? subfield set, so it enables protection and transmits its Beacon with the ?¡é?€??Use Protection?¡é?€?? subfield turn on. BSS#2?¡é?€??s beacon is heard by BSS#1?¡é?€??s AP and it also activates protection. Problem: Protection is now activated but no BSS has a Non-ERP STA associated.
Look at Devinator?¡é?€??s white paper at the disabling protection example (page 11 and 12) and notice how these two sub fields are use.
Hope that is the question you wanted answering. Otherwise I have just gone off on a tangent.
It may appear that one ERP AP "instructs" other ERP APs what to do regarding ERP protection, but I do not find this idea in the IEEE 802.11 standard, as amended.
1. "Non-ERP present" is an advisory provided by an ERP AP station. The corresponding bit must be set if a non-ERP station is associated to that ERP AP.
Other than that, vendors of other ERP stations in the same or nearby basic service set(s) (BSS) can code their ERP babies to do whatever they care to with the incoming information. Implementations vary.
2. "Use Protection" is a command provided by an ERP AP station to associated ERP stations of that BSS. The corresponding bit must be set if a non-ERP station is associated to that ERP AP. All ERP stations of that BSS, hearing the instruction, must use ERP protection mechanism(s) thereafter.
Other than that, vendors of other ERP stations in nearby BSSs can code their ERP babies to do whatever they care to with the incoming information. Implementations vary.
Whether ERP protection ripples across BSSs or not is up to our ERP vendors.
I hope this helps. Thanks. /criss
ERP protection can be disabled, by disabling the modulations required by the frames that give ERP protection their effect.
An ERP BSS with only OFDM rates enabled will neither be burdened by the sometimes persistent and apparently pointless overhead of ERP protection mechanisms, nor be protected from occasionally debilitating retransmissions occasioned by collisions with non-ERP stations (not members of this BSS).
This makes for a great lab demonstration but a bad enterprise model.
I hope this helps. Thanks. /criss
Hi Criss, thanks for your helpful comments.
I agree one ERP station does not ?¡é?€??instruct?¡é?€?? another ERP station to enable protection. It is left up to the AP that if it becomes aware of a neighbouring co-channel BSS having NonERP traffic it can enable protection. This idea comes from clause 9.10 of the 802.11g-2003 standard:
?¡é?€??In the case of a BSS composed of only ERP STAs, but with knowledge of neighbouring co-channel BSS having NonERP traffic, the AP may require protection mechanisms to protect the BSS?¡é?€??s traffic from interference?¡é?€??
One way an AP might get knowledge of neighbouring BSS having NonERP traffic is from reading the Non-ERP Present subfield.
I don't know if I agree with your example of the 3 BSSs. I mean, couldn't that same thing happen the way it is? The Protection Ripple has everything to do with the "Use Protection" subfield and nothing to do with the "Non-ERP Present" subfield if I am not mistaken.
I guess what I'm saying is that I have to disagree with your statement that the Non-ERP Present subfield is used to enable protection in a neighboring BSS.
The bottom line here is that you guys are missing the broader point. There *is* a big difference in the real world behavior of stations connected to a BSS that has Non-ERP Present set to 1 and a BSS that has Non-ERP Present set to 0. (I'll come clean at this point and admit that I was the one who told Gene to start this whole fracas.)
Who can tell Gene and me what that difference in behavior is?