Forum

Hi Murali:

Short preamble was introduced with the IEEE 802.11 clause 18 HR/DSSS PHY described in the 802.11b amendment document. Using short preamble is a throughput enhancement when all STAs support it, but a compatibility problem when some don't. Supporting it is optional both for transmission and reception of HR/DSSS STAs. I don't know but imagine that virtually all HR-DSSS devices sold today support both transmitting and receiving short preamble.

IEEE 802.11 clause 19 ERP PHY, described in the 802.11g amendment document, is required to support receiving short preamble. I don't know but imagine that virtually all ERP devices sold today also support transmitting short preamble.

IEEE 802.11 clause 15 DSSS PHY, described in the 802.11-1999 base document, cannot receive nor transmit short preamble. The DSSS PHY specification was created before the "short preamble" bit in the capability information field was defined. A DSSS client STA ignores this bit in beacons and sets this bit to 0 by default in its association requests.

A beaconing AP that says "Short Preamble capability=1" is saying "short preamble is allowed in this BSS," while 0 means "short preamble is not allowed in this BSS." If the DSSS client STA requests association, it is up to the vendor of the AP which supports short preamble to decide what to do. I imagine three alternatives.

1. Deny the association.

2. Allow the association and continue to allow short preamble in the BSS. This may optimize BSS performance.

3. Allow the association and change to disallow short preamble in the BSS. This optimizes BSS compatibility and may jeopardize performance.

I hope this helps. Thanks. /criss