7.3.2.13 ERP Information element

The ERP Information element contains information on the presence of
Clause 15 or Clause 18 stations in the BSS that are not capable of
Clause 19 (ERP-OFDM) data rates. It also contains the requirement of
the ERP Information element sender (AP in a BSS or STA in an IBSS) as
to the use of protection mechanisms to optimize BSS performance and as
to the use of long or short Barker preambles. See Figure 42E for a
definition of the frame element.

If one or more NonERP STAs are associated in the BSS, the
Use_Protection bit shall be set to 1 in transmitted ERP Information
Elements.

In an IBSS, the setting of the Use_Protection bit is left to the STA.
In an IBSS, there is no uniform concept of association; therefore, a
typical algorithm for setting the Use_Protection bit will take into
account the traffic pattern and history on the network. If a member of
an IBSS detects one or more NonERP STAs that are members of the same
IBSS, then the Use_Protection bit should be set to 1 in the ERP
Information Element of transmitted Beacon and Probe Response frames.

The NonERP_Present bit shall be set to 1 when a NonERP STA is
associated with the BSS. Examples of when the NonERP present bit may
additionally be set to 1 include, but are not limited to, when:

a) A NonERP infrastructure or independent BSS is overlapping (a NonERP
BSS may be detected by the reception of a Beacon where the supported
rates contain only Clause 15 or Clause 18 rates).

b) 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.

c) A management frame (excluding a Probe Request) is received where the
supported rate set includes only Clause 15 or Clause 18 rates.

ERP APs and ERP STAs shall invoke the use of a protection mechanism
after transmission or reception of the Use_Protection bit with a value
of 1 in an MMPDU to or from the BSS that the ERP AP or ERP STA has
joined or started. ERP APs and ERP STAs may additionally invoke
protection mechanism use at other times. ERP APs and ERP STAs may
disable protection mechanism use after transmission or reception of the
Use_Protection bit with a value of 0 in an MMPDU to or from the BSS
that the ERP AP or ERP STA has joined or started.

When there are no NonERP STAs associated with the BSS and the ERP
Information Element sender s dot11ShortPreambleOptionImplemented MIB
variable is set to true, then the Barker_Preamble_Mode bit may be set
to 0. The Barker_Preamble_Mode bit shall be set to 1 by the ERP
Information Element sender if one or more associated NonERP STAs are
not short preamble capable as indicated in their Capability Information
field, or if the ERP Information Element senders
dot11ShortPreambleOptionImplemented MIB variable is set to false.

If a member of an IBSS detects one or more non-short preamble-capable
STAs that are members of the same IBSS, then the Barker_Preamble_Mode
bit should be set to 1 in the transmitted ERP Information Element.

ERP APs and ERP STAs shall use long preambles when transmitting Clause
15, Clause 18, and Clause 19 frames after transmission or reception of
an ERP Information Element with a Barker_Preamble_Mode value of 1 in an
MMPDU to or from the BSS that the ERP AP or ERP STA has joined or
started, regardless of the value of the short preamble capability bit
from the same received or transmitted MMPDU that contained the ERP
Information Element. ERP APs and ERP STAs may additionally use long
preambles when transmitting Clause 15, Clause 18, and Clause 19 frames
at other times. ERP APs and ERP STAs may use short preambles when
transmitting Clause 15, Clause 18, and Clause 19 frames after
transmission or reception of an ERP Information Element with a
Barker_Preamble_Mode value of 0 in an MMPDU to or from the BSS that the
ERP AP or ERP STA has joined or started, regardless of the value of the
short preamble capability bit from the same received or transmitted
MMPDU. NonERP STAs and NonERP APs may also follow the rules given in
this paragraph.

Recommended behavior for setting the Use_Protection bit is contained in
9.10.

9.10 Protection mechanism

The intent of a protection mechanism is to ensure that a STA does not
transmit an MPDU of type Data or an MMPDU with an ERP-OFDM preamble and
header unless it has attempted to update the NAV of receiving NonERP
STAs. The updated NAV period shall be longer than or equal to the total
time required to send the data and any required response frames. ERP
STAs shall use protection mechanisms (such as RTS/CTS or CTS-to-self)
for ERP-OFDM MPDUs of type Data or an MMPDU when the Use_Protection
field of the ERP Information element is set to 1 (see the requirements
of 9.2.6). Protection mechanisms frames shall be sent using one of the
mandatory Clause 15 or Clause 18 rates and using one of the mandatory
Clause 15 or Clause 18 waveforms, so all STAs in the BSA will know the
duration of the exchange even if they cannot detect the ERP-OFDM
signals using their CCA function.

Note that when using the Clause 19 options, ERP-PBCC or DSSS-OFDM,
there is no need to use protection mechanisms, as these frames start
with a DSSS header.

In the case of a BSS composed of only ERP STAs, but with knowledge of a
neighboring co-channel BSS having NonERP traffic, the AP may require
protection mechanisms to protect the BSS s traffic from interference.
This will provide propagation of NAV to all attached STAs and all STAs
in a neighboring co-channel BSS within range by BSS basic rate set
modulated messages. The frames that propagate the NAV throughout the
BSS include RTS/CTS/ACK frames, all data frames with the more fragments
field set to 1, all data frames sent in response to PS-Poll that are
not proceeded in the frame sequence by a data frame with the more
fragments field set to 1, Beacon frames with nonzero CF time, and
CF-End frames.

When RTS/CTS is used as the protection mechanism, cases exist such as
NAV resetting (discretionary, as indicated in 9.2.5.4), where a hidden
station may reset its NAV and this may cause a collision. The
likelihood of occurrence is low, and it is not considered to represent
a significant impairment to overall system operation. A mechanism to
address this possible situation would be to use alternative protection
mechanisms, or to revert to alternative modulation methods.

If a protection mechanism is being used, a fragment sequence may only
employ ERP-OFDM modulation for the final fragment and control response.

The rules for calculating RTS/CTS NAV fields are unchanged when using
RTS/CTS as a protection mechanism.

Additionally, if any of the rates in the BSSBasicRateSet of the
protection mechanism frame transmitting STA s BSS are Clause 15 or
Clause 18 rates, then the protection mechanism frames shall be sent at
one of those Clause 15 or Clause 18 basic rates.
