Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretations for IEEE Std 802.11a™-1999 Supplement to IEEE Std for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High-speed Physical Layer in the 5 GHZ Band

Copyright © 2008 by the Institute of Electrical and Electronics Engineers, Inc. Three Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

This is an interpretation of IEEE Std 802.11a-1999.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

November 2008

Interpretation Request/Response #1 (1-11/04) PDF
Topic: Annex G accuracy Relevant Clauses: Annex G Classification: Conflicts with Clause 17

Interpretation Request #2
3-05/03 (802.11a channels) Topic: 802.11a channel definitions Relevant Clauses:,, Classification: unambiguous
In IEEE Std. 802.11a-1999, 200 channels are defined, one each centered every 5 MHz from 5000 MHZ to 6000 MHz. Yet only 12 of these channels are defined as legal and only in the US-NII radio bands. How are legal channels defined for regulatory domains, other than the US?

Interpretation Response #2
The standard defines as valid a set of only those channels for use in the US U-NII band. See clause for this definition. It does not define how other sets of valid channels are defined. Current work in both 802.11h™ and 802.11j™ are addressing this issue. This item is being brought to the attention of the 802.11™ working group for the possibility of action in a future revision or maintenance change.

Interpretation Request #3
1-11/04 (Annex G acccuracy) Topic: Accuracy of material in Annex G Relevant Clauses: Annex G Classification: Conflicts with clause 17

A possible mistake was found while working with IEEE 802.11a™ standard, as follows:
  1. Designation of the standard, including the year of publication. IEEE Std 802.11a-1999 Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications High-speed Physical Layer in the 5 GHz Band
  2. The specific subsection being questioned. Annex G. An example of encoding a frame for OFDM PHY. Table G.17-Last 144 bits scrambling.
  3. The applicable conditions for the case in question.

In order to check if our design of the PHY is correct, we have check it by means of the example given in Annex G "An example of encoding a frame for OFDM PHY".

All our results match properly with those given in all the tables except for 'Table G.17-Last 144 bits after scrambling'. In this case, the bits number 818 and 820 which are in the standard are '0'. However, we obtain two '1'.

In order to check if the scrambler module works properly we have tried to obtain the 127-bit repetitive sequence given in page 16 in chapter ' PLCP DATA scrambler and descrambler' and we do it correctly. As it can be seen, the values of the 7-bit shift register of the scrambler depends only on the seed. In the example given, the seed is '1011101' and we have checked as well that we match the 'Table G.15- Scrambling sequence for seed 1011101'. Therefore, in our opinion the mismatch in 'Table G.17' might be caused by the input of the scrambler, that is, the DATA bits. However, we are obtaining the same values than those given in 'Table G.14-Last 144 DATA bits'.

After all this explanation, i would be really grateful if you could confirm to us that the data showed at 'Table G.17' are completely correct or if there is any mistakes on it.

Interpretation Response #3
In document 11-04-1198-00-00m, an analysis of the material in question is provided in Annex G. This analysis is reproduced here.

  • The two bits (bit#818 and bit#820) in the Table G.17 should be corrected
    • Both of bit #818 and bit #820 in the Table G.17 are “0” in current standard.
    • Both bit #818 and bit #820 should be modified to be “1”.
  • Table G.1: Table G.1 consists of following items.
    • The MAC header (24 octets)
    • The first 72 characters of the original message converted to ASCII code
    • The CRC32 (4 octets)
    • A PSDU of length 100 octets (= 800 bits) {04 02 00 2e 00 60 08 cd … 74 72 65 61 da 57 99 cd}
  • Generation of DATA field in PPDU frame:
    • The DATA field in a PPDU frame consists of SERVICE field, PSDU, tail (PPDU TAIL) and Pad bits.
    • Table G.13 shows the first 144 bits of the DATA field.
  • The SERVICE field (sixteen “0” bits) are added before PSDU.
  • Table G.14 shows the last 144 bits of the DATA field.

Assuming the modulation mode of 36M bps (16QAM, r=3/4), 42 Pad bits are appended in this case.

Table G.15 – Scrambling sequence for seed 1011101 – This is the output sequence of the scrambler when the initial value of the shift register is 1011101. – We have confirmed that the Table G.15 was correct.

We have confirmed that: – Table G.16 (First 144 bits after scrambling) was correct. – Table G.17 (Last 144 bits after scrambling) was NOT correct as the requester pointed out.

See Interpretation #1 for Table G.17. The bit #818 and bit #820 in the Table G.17 correspond to the PPDU TAIL bits. • The PPDU TAIL bits and PAD bits are all “0” o There will be exact sequence of the scrambler output after bit #816 in the Table G.17. o The bits #818 and #820 in the Table G.17 correspond the bits #56 and #58 in the Table G.15 which have value of “1”.

The conclusion of this analysis is that two bits in table G.17 are in error. This error will be brought to the attention of the 802.11 working group to be addressed in the next revision of the standard.

Interpretation Request #4
1-07/06 (RTS/CTS with fragmentation) Topic: ambiguity of RTS/CTS usage description with fragmentation Relevant Clauses:,,,, 9.2.8, 9.7 Classification: Unambiguous

Clause states that: RTS-CTS mechanism precedes the first fragment only in case of transmission of multiple fragments by a source STA, where (RTS threshold < Fragmentation Threshold). It also says "no further RTS/CTS frames need to be generated after the RTS/CTS that began the frame exchange sequence even though subsequent fragments may be larger than dot11RTSThreshols". The section also discusses the worst-case scenario, where an acknowledgment of a fragment is lost and is never heard by the source station.

How does the frame transmission begin when there is an acknowledgment loss? Will there be an RTS-CTS exchange by the source STA again before retrying the lost fragment?

Clause says that the RTS-CTS mechanism should only occur before the transmission of the first fragment; the Frame Exchange Sequence in clause 9.7 also depicts this behavior, i.e. {RTS-CTS-}[Frag - ACK -]Last - ACK

However, clause states: "When a source STA transmits a fragment, it shall release the channel, then immediately monitor the channel for an acknowledgment.

If no acknowledgment is received, then should the source STA perform a random backoff and contend for the channel? Would the source STA be required to send a RTS at this point to reserve the NAV again after gaining access on the channel?

The standard is not clear from these clauses what the desired behavior should be.

Interpretation Response #4
The standard is unambiguous on this issue. Clauses,,, and 9.2.8 describe the use of the backoff procedure in various situations, including that when an ACK is not received in response to an individually addressed data frame (fragment). The description of fragmentation in the standard does not modify this behavior. Therefore, the standard requires a backoff procedure to be performed after loss of an ACK frame.

Clause 9.2.6 describes the requirement to use RTS before the transmission of any MPDU longer than dot11RTSThrshold. Clause modifies this general requirement when transmitting a fragment burst. RTS/CTS is required to precede the initial fragment in a fragment burst and is required not to be transmitted before any other fragments in that same fragment burst. Clause 9.7 also shows RTS/CTS preceding the initial fragment of a fragment burst.

The standard is unambiguous on the topic of RTS/CTS usage with fragmentation.

Interpretation Request #5
1-09/06 (Unknown values in information elements) Topic: requirements for operation of an implementation when encountering unknown values in an information element Classification: Unambiguous

The current description of Information elements in 7.3.2 is vague about the processing of unknown element-specific information fields, in contrast with the processing of unknown information element fields:

A STA that encounters an unknown or reserved element ID value in a management frame received without error shall ignore that element and shall parse any remaining management frame body for additional information elements with recognizable element ID values.

An example would be an 802.11j conformant STA that receives a Country Information Element for Japan with a Regulatory Class value of 21, which was reserved at the time of 802.11j approval, but has subsequently become specified.

Proposal: Change the current text to include the processing of unknown element-specific information fields:

A STA that encounters an unknown or reserved element ID value [or unknown element-specific information field] in a management frame received without error shall ignore that element [or unknown element-specific information field,] and shall parse any remaining management frame body for additional information elements with recognizable element ID values.

Interpretation Response #5
The standard is silent on this matter, in general. It does not specify any particular action to be taken by a compliant implementation in the situation described by the requester. There are specific requirements for some fields in some information elements, but not all.

This issue will be forwarded to the 802.11 Working Group for consideration in a future revision of the standard.