ERP
. . . .

ERP

  • 802.11g radios used a new technology called Extended Rate Physical (ERP)
  • Uses 2.4 GHz to 2.4835 GHz ISM frequency band.
  • Two mandatory and two optional ERP physical layers (PHYs) were defined by the 802.11g amendment.
    The mandatory PHYs are ERP-OFDM and ERP-DSSS/ CCK.
  • To achieve the higher data rates, a PHY technology called Extended Rate Physical OFDM (ERP-OFDM) was mandated.
  • Possible data rates of 6, 9, 12, 18, 24, 36, 48, and 54 Mbps, although IEEE standard only requires the data rates of 6, 12, and 24 Mbps.
  • To maintain backward compatibility with 802.11 (DSSS only) and 802.11b networks, a PHY technology called Extended Rate Physical DSSS (ERP-DSSS/ CCK) is used with support for the data rates of 1, 2, 5.5, and 11 Mbps.

Difference between ERP-DSSS/ CCK, DSSS, and HR-DSSS

  • From a technical viewpoint, there is no difference between ERP-DSSS/ CCK and DSSS and HR-DSSS.
  • A key point of the 802.11g amendment was to maintain backward compatibility with older 802.11 (DSSS only) and 802.11b radios while at the same time achieving higher data rates.
  • 802.11g devices (Clause 19 radios) use ERP-OFDM for the higher data rates.
  • ERP-DSSS/ CCK is effectively the same technology as DSSS that is used by legacy 802.11 devices (Clause 16 radios) and HR-DSSS that is used by 802.11b devices (Clause 17 radios).
  • Support for ERP-DSSS/ CCK allows for backward compatibility with older 802.11 (DSSS only) and 802.11b (HR-DSSS) radios

Backward compatibility

  • ERP-OFDM and ERP-DSSS/ CCK technologies can coexist, yet they cannot speak to each other.
  • 802.11b and 802.11g stations can coexist in the same BSS by using either the RTS/ CTS or CTS-to-Self protection mechanism.
    This protection mechanism is also the foundation for coexistence between 802.11n devices and earlier legacy devices.
  • The goal of the protection mechanism is to prevent older 802.11b HR-DSSS or 802.11 DSSS radio cards from transmitting at the same time as 802.11g (ERP) radios.

Mixed mode (b/g)

In a mixed-mode environment, when an 802.11g device wants to transmit data it will:
  1. Perform a NAV distribution by transmitting a request to send/ clear to send (RTS/ CTS) exchange with the AP or by transmitting a CTS-to-Self using a data rate and modulation method that the 802.11b HR-DSSS stations can understand.
  2. The RTS/ CTS or CTS-to-Self will hopefully be heard and understood by all of the 802.11b and 802.11g stations.
    The RTS/ CTS or CTS-to-Self will contain a Duration/ ID value that will be used by all of the listening stations to set their NAV timers. To put it simply, using a slow transmission that all stations can understand, the ERP (802.11g) device notifies all the stations to reset their NAV values.
  3. After the RTS/ CTS or CTS-to-Self has been used to reserve the medium, the 802.11g station can transmit a data frame by using OFDM modulation without worrying about collisions with 802.11b HR-DSSS or legacy 802.11 DSSS stations.
 
  • Within an ERP basic service set, the HR-DSSS (802.11b) and legacy 802.11 DSSS stations are known as non-ERP stations.
  • This allows the ERP stations to use the higher ERP-OFDM data rates to transmit and receive data yet still maintain backward compatibility with the older legacy non-ERP stations.
  • The protection mechanism is triggered when an ERP (802.11g) AP decides to enable the use of a protection mechanism, it needs to notify all of the ERP (802.11g) stations in the BSS that protection is required.
  • It accomplishes this by setting the NonERP Present bit, and the ERP stations will know that Protected mode is required.
  • There are an assortment of reasons why Protected mode may be enabled. The following are three scenarios that can trigger protection in an ERP basic service set:

  1. If a non-ERP STA associates with an ERP AP, the ERP AP will enable the NonERP_Present bit in its own beacons, enabling protection mechanisms in its BSS. In other words, an HR-DSSS (802.11b) client association will trigger protection.
  2. If an ERP AP hears a beacon from an AP where the supported data rates contain only 802.11b or 802.11 DSSS rates, it will enable the NonERP_Present bit in its own beacons, enabling protection mechanisms in its BSS.
  3. In simpler terms, if an 802.11g AP hears a beacon frame from an 802.11 or 802.11b AP or ad hoc client, the protection mechanism will be triggered.
  4. If an ERP AP hears a management frame (other than a probe request) where the supported rate includes only 802.11 or 802.11b rates, the NonERP_Present bit may be set to 1.

How Does 802.11b Affect 802.11g Throughput?

  • A common misconception is that 802.11g radios revert to 802.11b data rates when the protection mechanism is used.
  • In reality, ERP (802.11g) radios still transmit data at the higher ERP-OFDM rates.
  • However, when an HR-DSSS (802.11b) station causes an ERP (802.11g) BSS to enable the protection mechanism, a large amount of RTS/ CTS or CTS-to-Self overhead is added prior to every ERP-OFDM data transmission.
  • The aggregate data throughput loss is caused by the extra overhead and not by using slower 802.11b rates.
  • A data rate of 54 Mbps usually will provide about 18 Mbps to 20 Mbps of aggregate throughput when protection is not enabled.
  • After protection is enabled, the overhead will reduce the aggregate data throughput to below 13 Mbps— and possibly as low as 9 Mbps.

RTS/CTS

  • In order for a client station to participate in a BSS, it must be able to communicate with the AP.
  • This is straightforward and logical; however, it is possible for the client station to be able to communicate with the AP but not be able to hear or be heard by any of the other client stations.
  • This can be a problem because, as you may recall, a station performs collision avoidance by setting its NAV when it hears another station transmitting (virtual carrier sense) and by listening for RF (physical carrier sense).
  • If a station cannot hear the other stations, or cannot be heard by the other stations, there is a greater likelihood that a collision can occur.
  • Request to send/ clear to send (RTS/ CTS) is a mechanism that performs a NAV distribution and helps prevent collisions from occurring.
  • This NAV distribution reserves the medium prior to the transmission of the data frame.
  • When RTS/ CTS is enabled on a station, every time the station wants to transmit a frame it must perform an RTS/ CTS exchange prior to the normal data transmissions.
  • When the transmitting station goes to transmit data, it first sends an RTS frame.
  • The duration value of the RTS frame resets the NAV timers of all listening stations so that they must wait until the CTS, DATA, and ACK have been transmitted.
  • The receiving station, the AP, then sends a CTS, which is also used for NAV distribution.
  • The duration value of the CTS frame resets the NAV timer of all listening stations so that they must wait until the DATA and ACK have been transmitted.
  • As you can see in Figure 9.10, the duration value of the RTS frame represents the time, in microseconds, that is required to transmit the CTS/ DATA/ ACK exchange plus three SIFS intervals.
  • The duration value of the CTS frame represents the time, in microseconds, that is required to transmit the DATA/ ACK exchange plus two SIFS intervals.
  • If any station did not hear the RTS, it should hear the CTS. When a station hears either the RTS or the CTS, it will set its NAV to the value provided.
  • At this point, all stations in the BSS should have their NAV set, and the stations should wait until the entire data exchange is complete.
  • Figure 9.11 depicts an RTS/ CTS exchange between a client station and an AP.
  • RTS/ CTS is used primarily in two situations.
    1. It can be used when a hidden node exists,
    2. it can be used automatically as a protection mechanism when different technologies such as 802.11b/ g/ n coexist in the same basic service set.
Picture
RTS/CTS Duration values
Picture
RTS/CTS Frame exchanges
CTS-to-Self

  • CTS-to-Self is used strictly as a protection mechanism for mixed-mode environments.
  • One of the benefits of using CTS-to-Self over RTS/ CTS as a protection mechanism is that the throughput will be higher because fewer frames are being sent.
  • When a station using CTS-to-Self wants to transmit data, it performs a NAV distribution by sending a CTS frame.
  • This CTS notifies all other stations that they must wait until the DATA and ACK have been transmitted.
  • Any station that hears the CTS will set their NAV to the value provided. Since CTS-to-Self is used as a protection mechanism for mixed-mode environments, the ERP (802.11g) station will transmit the CTS by using DSSS technology that all stations can understand. Then the DATA and the ACK will be transmitted at a faster 802.11g speed by using ERP-OFDM data rates.
  • CTS-to-Self is better suited for use by an AP.
  • It is important to make sure that all stations hear the CTS to reserve the medium, and this is most likely to occur if it is being sent by an AP.
  • If a client station were to use CTS-to-Self, there is a chance that another client station on the opposite side of the BSS might be too far away from the CTS-to-Self and would not realize that the medium is busy.
  • Even though this is true, from our experience, it appears that most use CTS-to-Self on client stations to reserve the medium instead of RTS/ CTS.
  • CTS-to-Self is used because of the decreased overhead when compared with RTS/ CTS.
  • Some vendors allow the user to select whether the client station uses RTS/ CTS or CTS-to-Self when in Protected mode.
Reference:
Coleman, David D.,Westcott, David A. CWNA: Certified Wireless Network Administrator Official Study Guide: Exam CWNA-106 Wiley.
© COPYRIGHT 2023. ALL RIGHTS RESERVED.