Interpretations

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

IEEE Standards Interpretation for IEEE Std 802.11™-1999 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

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

This is an interpretation of IEEE Std 802.11-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 #1
1-01/04 (Undefined information elements) Topic: Definition of certain information elements Relevant Clauses: 7.3.2 Classification: unambiguous

In 2002, the 802.11 Working Group created a set of Element IDs, defining the use of many information elements defined as "Reserved" in the standard. Many of these element IDs are assigned for the use of individual companies.

An additional element ID is defined as a "vendor-specific" information element. The format and use of these newly defined information elements is not described in the standard or any of its supplements.

What is the form of each of the information elements defined by the newly assigned element IDs, when are they used, and in which frames may they appear?

Interpretation Response #1
The standard defines the information element IDs that are the subject of the interpretation request as "reserved." This includes the working group-assigned information element IDs for the use of individual companies and the "vendor-specific" information element. This indicates that the element IDs may be used in a future amendment of the standard. The standard does not provide any definition of the use of these information element IDs for individual company use or for use as a "vendor-specific" information element. The request has been forwarded to the 802.11 working group for consideration of inclusion in a future revision or maintenance release of the standard.

Interpretation Request #2
(3-05/03) Topic: 802.11a channel definitions Relevant Clauses: 17.3.8.3.1 , 17.3.8.3.2, 17.3.8.3 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 17.3.8.3.3 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
(use of short and long retry counters) Topic: ambiguity of usage of short and long retry counters after RTS/CTS failure Relevant Clauses:9.2.5.3, 9.2.5.7, C.3 Classification: Ambiguous

According to 9.2.5.3 "After an RTS frame is transmitted, the STA shall perform the CTS procedure, as defined in 9.2.5.7. If the RTS transmission fails, the short retry count for the MSDU or MMPDU and the STA short retry count are incremented."

However, in Annex C.3 (page 348), in the case of a RTS failure, the only counters which are incremented are the long one's (the short one's are not modified in this case).

Is the Annex and the Clause in conflict?

Interpretation Response #3
The standard is ambiguous on this issue. Clause 9.2.5.3 and 9.2.5.7 describe the use of the use of the short and long retry counters, when the CTS is not received in response to a transmitted RTS. Annex C.3 also describes this operation. These two descriptions of the requirements of an implementation are in conflict with each other.

The standard is ambiguous on this issue. The issue will be forwarded to the 802.11 Working Group for consideration in a future revision of the standard.

Interpretation Request #4
1-05/03 (status codes) Topic: 802.11 status codes Relevant Clauses: 7.3.1.9 Classification: unambiguous

In clause 7 there are several status codes defined that appear in several different frames. Yet, when each of these status codes is to be transmitted and any action to be taken by a station upon reception of these status codes is not specified. Please specify the use of the status codes on both transmission and reception.

Interpretation Response #4
The standard defines as valid a set of status codes for use in management frames defined in clause 7 and in MLME primitives defined in clause 10. Normative behavior is provided for status code 0,  corresponding to successful status code. Transmission of some status codes during authentication, association and re-association processes are described in Annex C. The standard does not define normative behavior for transmitting other status codes. Reception of status codes is defined by the standard in that the code is passed across the MLME SAP interface to an external entity outside the scope of the standard. 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 #5
2-05/03 (status codes) Topic: 802.11 reason codes Relevant Clauses: 7.3.1.7 Classification: unambiguous

In clause 7 of IEEE Std. 802.11-1999, the content of a Reason Code field is defined that appears in several different 802.11 frames. There is not any definition of the use of each of the different reason codes on transmission nor any definition of the behavior of a station upon reception of these reason codes. Please define the use of these reason codes for both transmission and reception.

Interpretation Response #5
The standard defines as valid a set of reason codes for use in management frames defined in clause 7 and in MLME SAP primitives defined in clause 10. Transmission of some reason codes during authentication, association and re-association processes are described in Annex C. The standard does not define normative behavior for transmitting other reason codes. Reception of reason codes is defined by the standard in that the code is passed across the MLME SAP interface to an external entity outside the scope of the standard. 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 #6
4-05/03 (Country Information Element) Topic: Country Information Element Relevant Clauses: 7.3.2.9 (7.3.2.12 from the requester), 17.3.8.3.3 Classification: unambiguous

The current description of the country information element is vague about the precise contents of the country information element. It remains unclear whether the country information must always contain the full set of regulatory domain information as specified by the regulatory administrations or that a subset of the regulatory domain information can be used as specified by the network operator. Furthermore, it is ambiguous how the country information element should be used in the 5GHz band.

The country information element contains the information required to allow a station to identify the regulatory domain in which the station is located and to configure its PHY for operation in that regulatory domain.

Element ID Length
Country String (Octets 1, 2)
Country String (Octet 3) First Channel Number
Number of Channels Maximum Transmit Power Level
First Channel Number Number of Channels
Maximum Transmit Power Level Pad (if needed)

Figure 42A -- Country Information Element

The country information element allows the definition of multiple sub bands with each their own maximum transmit power levels. The rules specified for these sub bands are:

  • sub band ranges must not overlap;
  • sub bands must monotonically increase.

This definition does not demand that sub bands exactly fill up the regulatory channels.

For example, this definition allows network operators to create a country element as follows: The country element contains three sub bands.  

  • The First Channel Number element of the first sub band is set to channel 1 and the Number of Channels element is set to one.
  • The First Channel Number element of the second sub band is set to channel 5 and the Number of Channels element is set to one.
  • The First Channel Number element of the third sub band is set tot channel 9 and the Number of Channels element is set to one.

The resulting country information element is valid within the FCC regulatory domain and might be valid to the definition of the country information element in the IEEE 802.11d standard.

STAs that use the above country information to determine the regulatory domain, will only mark channels 1, 5 and 9 as regulatory permitted and will not look for networks at the other channels. Although this may improve the scanning behavior of STAs, we believe this is not what the country information element is intended for according to the definition in the first paragraph of section 7.3.2.12 (lines 30-32 of page 1 of this document).

Proposal Change text to clearly state that the country information element must be used to inform STAs about the full regulatory domain of operation. Sub bands may only be used if the regulatory domain consists of sub bands.

Proposed text change (802.11d, page 4, paragraph 4): Change "The group of channels described .. increasing in channel numbers." into "The group of channels described by each pair of the First Channel Number and Number of Channels fields shall not overlap, shall be monotonically increasing in channel numbers and shall describe all channels allowed in the regulatory domain."

Interpretation Response #6
The definition of the use of the Country information element in either of the cases described by the requester is allowed in the standard. The Country information element provides a mechanism to communicate information relevant to the configuration of a radio necessary for proper operation in a regulatory domain. The standard does not limit the use of this mechanism to transfer only information identical to that required for the full use of bands (or sub-bands) defined for the regulatory domain.

It is possible that some clarifying text might be helpful to guide the implementer to the expect either of these uses of the mechanism. This is being brought to the attention of the 802.11 working group with the possibility of action in a future revision or maintenance change.

Interpretation Request #7
4-05/03 (Country Information Element) Topic: Country Information Element Relevant Clauses: 7.3.2.9 (7.3.2.12 from the requester), 17.3.8.3.3 Classification: unambiguous

Ambiguous definition in 5GHz band
It is not defined how to use the country information element in the 5GHz band. Unlike the 2GHz band, in the 5GHz band channels numbers specify the center frequencies of 20MHz wide channels. Channel numbers below 240 are encoded as steps of 5MHz from the 5GHz base (e.g. channel 36 =< 5GHz + (36*0.005) = 5.18GHz). Channel numbers from 240 and up are defined as negative channel numbers with steps of 5MHz from base 5GHz (e.g. channel 240 = 5GHz – (16*0.005) = 4.92GHz).

Channels in the 5GHz band are always spaced 20MHz apart. If the channel number of a channel is 40, its neighboring channels will have channel numbers 36 and 44 respectively.

The ambiguity in the country information element is the definition of a sub band in the 5GHz. If the channel number is set to 36 and the number of channels is set to 4, does this imply that this sub band consists of channels 36, 40, 44 and 48 or consists of channels 36, 37, 38 and 39? The latter definition would not make any sense with respect to the 20MHz wide channels.

Proposal Add text to describe that the channel number specifies the first channel of the sub band and that in the 5GHz band the number of channels specifies the number of 20MHz wide channels in the sub band.

Proposed text addition (802.11d, page 4, paragraph 5): Add following text after: "The Number of Channels field .. in length." "In the 5GHz band, it shall contain a positive integer value that indicates the number of 20MHz wide channels in the sub band adjacent to the first channel. Expressed in channel numbers this implies that the last channel in the sub band will have channel number First Channel Number + ((Number of Channels –1) * 4)."

Interpretation Response #7
Because the channel numbers are specific to a particular PHY, it is critical to understanding how the channel number and number of channels is used in the Country information element to refer to the definition of valid, or legal, channels defined in the PHY. For the instance cited by the requester, the 5 GHz PHY defines those valid channels in clause 17.3.8.3.3. For a First Channel Number of 36 and a Number of Channels of 4 in a Country information element the individual channel numbers defined for the 5 GHz PHY by these parameters are 36, 40, 44, and 48.

It is possible that some clarifying text might be helpful to guide the implementer to the information already in the standard. This is being brought to the attention of the 802.11 working group with the possibility of action in a future revision or maintenance change.

Interpretation Request #8
1-07/03 (delayed CFP Beacon) Topic: 802.11 Beacon Relevant Clauses:9.3.3.2 Classification: unambiguous

original line : In the case of a busy medium due to DCF traffic, the beacon shall be delayed for the time required to complete the current DCF frame exchange.

I think there is no direct answer about the following case.

Q: When a PCF beacon(CFPeriod=0, DTIM COunt=0) is defered due to a busy medium(DCF), PC shall use xxxxxxxxxx delay to start the CFP after this DCF medium busy.

A: <1> served as normal DCF beacon, use DIFS+random backoff delay <2> served as normal PCF beacon while not deffered by medium, use PIFS delay

Interpretation Response #8
Clause 9.3.3.2 says, in part: "… the PC shall use a DIFS plus a random backoff delay (with CW in the range of 1 to aCWmin) to start a CFP when the initial beacon is delayed because of deferral due to a busy medium." This is a clear statement that the Beacon is to be transmitted using a backoff after DIFS after the medium becomes idle.

This area of the standard is being modified by the work going on 802.11 Task Group e. You may be interested in following that work as it progresses.

Interpretation Request #9
1-09/03 (Contention window and retry counters) Topic: Reset of contention window to CWmin Relevant Clauses: 9.2.4, 9.2.5.3 Classification: unambiguous

According to the above sub-clauses, the Station {Short, Long} Retry counters are incremented every time a (Short/Long) retry counter associated with an MSDU is incremented. They are only reset upon successful transmission of an MPDU (of appropriate length).

The CW is 'controlled' by the Station counters, increasing in size every time either of the Station counters increases. It is reset to CWmin only

  1. after a successful MSDU transmission, or
  2. when either of the Station counters reaches their respective limit.

Consider a scenario where a station *continually* fails to transmit successfully: The CW will increase, until condition b) above is met, at which point it will revert to CWmin. However, the Station retry counters are not reset at this point, and will continue to increase; condition b) will not be met again, and CW will increase (or remain at CWmax) for all subsequent (failed) attempts, regardless of the state of the respective MSDU counters.

Is this the intended behavior? It seems odd that the CW will be reset after the first failure (when b) is met, and the MSDU is discarded), but not for subsequent MSDUs.

Interpretation Response #9
The requester’s interpretation of the standard is correct. The standard allows the contention window to be reset to CWmin in this situation only once, after which the CW value will progress to the largest value in the sequence and remain there until one of the conditions to reset the CW to CWmin is met. This behavior is intended to minimize the bandwidth wasted by a station that is unable to successfully exchange frames with its intended receiver(s).

Interpretation Request #10 (part 1)
2-09/03 (Maximum transmit power level in Country information element) Topic: Maximum transmit power level in Country information element Relevant Clauses: 7.3.2.9 Classification: unambiguous

The phrase "…maximum power…allowed to be transmitted" is ambiguous.  The most likely interpretations include:
  1. TPO (Transmitter Power Output)
  2. EIRP (Effective Isotropically Radiated Power)

Unfortunately, different administrations have regulations that are based on either TPO (e.g. FCC) or EIRP (e.g. ETSI), and in such a way that they cannot always be converted into one another. E.g. the FCC specifies a maximum TPO and allows up to 6dBi antenna gain. Above 6dBi the TPO should be reduced dB for dB, except for point-to-point links, where a higher antenna gain is allowed and less reduction is to be applied. This cannot be converted to an equivalent EIRP limit. ETSI specifies a plain EIRP limit. What is the interpretation of the Maximum Transmit Power Level field?

Interpretation Response #10 (part 1)
The interpretation of a value in the Maximum Transmit Power Level field of a Country information element does not need be expressed as TPO, EIRP, or any other particular means of measurement. The interpretation is defined by the regulations of the country identified in the Country String of the same information element. Assuming the examples provided by the requester are correct, this would mean that a value in the Maximum Transmit Power Level field of a Country information element with a Country String value of “US” would be interpreted as a measure of the TPO of the device, whereas a value in an information element where the value of the Country String is “NL” would be interpreted as a masue of the EIRP of the device.

Interpretation Request #10 (part 2)
Apart from a limit on radiated power, the regulations usually contain a PSD (Power Spectral Density) limit. In some domains, the PSD limit is more strict than the TPO/EIRP limit and thus further limits the transmitted power.

Example: The EIRP limit under ETSI regulations in the 5150-5350 MHz band is 200mW, but the PSD limit is 10mW/MHz EIRP. Since an OFDM signal has a bandwidth of 16MHz, the EIRP is further limited to approximately 160mW.

Should, in this case, the Maximum Transmit Power Level field be set to 200mW or 160mW?

If the interpretation is plain EIRP, the station will exceed PSD limits for certain countries, since the PSD limit is not part of the country information elements. How should in that case the PSD limit be derived? If the interpretation is to take the PSD limit into account in the Maximum Transmit Power Level, we have to integrate the PSD over the signal bandwidth to convert to total power. However, there is a problem in the 2.4GHz band, since the spectral shape for DSSS/CCK is not accurately defined, so that the conversion factor may depend on the transmitter filter implementation (and thus may vary for each client STA). What conversion factor should be used in that case?

Interpretation Response #10 (part 2)
The information in the Country information element provides an indication of the regulatory domain and the requirements of that domain. It is not expected that the information in the information element is sufficient to configure all of the parameters of a device to comply with the regulations in effect in the regulatory domain. The value of the Maximum Transmit Power Level is to contain the value specified in the regulations of the particular regulatory domain identified by the value of the Country String. It is up to each manufacturer to use the information in the Country information element, along with local configuration information, such as a power backoff value, to configure a device for operation that is compliant with the local regulations where the device is operating.

Interpretation Request #10 (part 3)
The Country Information Element does not indicate whether a particular subband has indoor/outdoor restrictions. How should this information be derived?

Interpretation Response #10 (part 3)
The Country information element provides, as part of the Country String, an indication as to whether the bands described in the information element are utilizing regulations that are differentiated for indoor and outdoor operation. While an access point or station may be sending a Beacon or Probe Response containing a Country information element that does not match the location of the receiver, i.e., an access point that is indoors might be received outdoors, it is expected that the receiver will utilize the information in the Country String and determine its local configuration based on that information. There is no mechanism specified in the standard to convey both indoor and outdoor information for a single band or to describe one or more subbands for indoor operation and one or more other subbands for outdoor operation.

Interpretation Request #11
1-01/04 (Use of Status and Reason Codes) Topic: Usage of Status and Reason Codes Relevant Clauses: 7.3.1.7, 7.3.1.9 Classification: unambiguous

Values for the Reason Code are defined in clause 7.3.1.7 and values for the Status Code are defined in clause 7.3.1.9. These values are to be included in various MAC Management frames. However, there is no definition of when a station or AP is to transmit a particular value for these items, nor what a station or AP is to do upon receipt of a particular value for these items.

How are the values for the Reason Code and Status Code to be selected for transmission and what is to be done upon reception of each code?

Interpretation Response #11
This request duplicates requests that have been received in the past. The response to these requests is available on the IEEE 802.11 web site at the following URLs:

http://www.ieee802.org/11/Interpretations/03-402r1-M-Interpretation_Response_02-0503.doc http://www.ieee802.org/11/Interpretations/03-401r1-M-Interpretation_Response_01-0503.doc

This information has been forwarded to the 802.11 working group for consideration of inclusion in a future revision or maintenance release of the standard.

Interpretation Request #12
2-01/04 (Undefined information elements) Topic: Definition of certain information elements Relevant Clauses: 7.3.2 Classification: unambiguous

In 2002, the 802.11 Working Group created a set of Element IDs, defining the use of many information elements defined as "Reserved" in the standard. Many of these element IDs are assigned for the use of individual companies. An additional element ID is defined as a "vendor-specific" information element. The format and use of these newly defined information elements is not described in the standard or any of its supplements.

What is the format of each of the information elements defined by the newly assigned element IDs, when are they used, and in which frames may they appear?

Interpretation Response #12
The standard defines the information element IDs that are the subject of the interpretation request as "reserved". This includes the working group-assigned information element IDs for the use of individual companies and the "vendor-specific" information element. This indicates that the element IDs may be used in a future amendment of the standard. The standard does not provide any definition of the use of these information element IDs for individual company use or for use as a "vendor-specific" information element. The request has been forwarded to the 802.11 working group for consideration of inclusion in a future revision or maintenance release of the standard.

Interpretation Request #13
1-03/04 (Adopting beacon parameters in an IBSS) Topic: Adopting beacon parameters in an IBSS Relevant Clauses: 3.8, 7.2.3, 7.3.2.2, 9.1.2, 10.3.3.1, 10.3.2.2, 11.1.2.2, 11.1.3, 11.1.4 Classification: ambiguous

11.1.4 says: "A STA receiving such a frame [a beacon] from another STA in an IBSS with the same SSID shall compare the Timestamp field with its own TSF time. If the Timestamp field of the received frame is later than its own TSF time, the STA shall adopt all parameters contained in the Beacon frame."

What is the meaning of "all parameters"” in this context? It’s clearly not just the TSF timer, or there would be no need to say “all” parameters. And if it includes information carried in IEs, does it, or does it not, include IEs which the STA does not recognize?

Interpretation Response #13
The items in question are identified in clause 10.3.3.1 (MLME-JOIN.request), which in turns references the enumerated list within BSSDescription in clause 10.3.2.2 (MLME-SCAN.confirm). Each BSSDescription consists of the following elements:  
  • BSSID – A STA in IBSS mode receiving this field in a beacon would adopt this value since this is the identification value for the IBSS assigned per clause 11.1.3.
  • SSID – A STA in IBSS mode receiving this field in a beacon would adopt this value, as stated explicitly in clause 11.1.4.
  • BSSType – A STA in IBSS mode receiving this field in a beacon would implicitly adopt this value, because the STA is operating in IBSS mode.
  • Beacon Period – A STA in IBSS mode receiving this field in a beacon would adopt this value, as stated explicitly in clause 11.1.2.2.
  • DTIM Period – A STA in IBSS mode receiving this field in a beacon would adopt this value, as stated explicitly in clause 11.1.2.2.
  • Timestamp – A STA in IBSS mode receiving this field in a beacon would adopt this value, as stated explicitly in clause 11.1.4.
  • Local time – This field is not applicable to this interpretation request since this is a local value used for computational purposes in adopting the TSF of the peer MAC entity (per clause 11.1.4) and is not a beacon parameter per se.
  • PHY parameter set – A STA in IBSS mode receiving this field in a beacon would adopt this value.
  • CF parameter set – A STA in IBSS mode receiving this field in a beacon would not adopt this value since a CFP is not allowed in an IBSS (per clause 9.1.2).
  • IBSS parameter set – A STA in IBSS mode receiving this field in a beacon would adopt this value.
  • Capability Information – A STA in IBSS mode receiving this field in a beacon would not adopt this value since this value in the local MAC entity must represent the advertised capabilities of the local MAC entity.
  • BSSBasicRateSet – Per clause 3.8, "the BSS basic rate set data rates are preset for all stations in the BSS". A STA participating in a BSS is required to "avoid associating with a BSS if the STA cannot receive and transmit all the data rates in the BSS basic rate set" per clause 7.3.2.2.

Processing of unknown IEs is defined in clause 7.2.3.

This information has been forwarded to the 802.11 working group for consideration of inclusion in a future revision or maintenance release of the standard.

Interpretation Request #14
2-09/06 (use of short and long retry counters) Topic: ambiguity of usage of short and long retry counters after RTS/CTS failure Relevant Clauses: 9.2.5.3, 9.2.5.7, C.3 Classification: Ambiguous

Object: Request for interpretation for IEEE Std 802.11-1999 Clause:9.2.5.3.

According to clause 9.2.5.3 "After an RTS frame is transmitted, the STA shall perform the CTS procedure, as defined in 9.2.5.7. If the RTS transmission fails, the short retry count for the MSDU or MMPDU and the STA short retry count are incremented." However, in annex C.3 (page 348), in the case of a RTS failure, the only counters which are incremented are the long one's (the short one's are not modified in this case).

Are the annex and the clause in conflict?

Interpretation Response #14
The standard is ambiguous on this issue. Clause 9.2.5.3 and 9.2.5.7 describe the use of the use of the short and long retry counters, when the CTS is not received in response to a transmitted RTS. Annex C.3 also describes this operation. These two descriptions of the requirements of an implementation are in conflict with each other.

The standard is ambiguous on this issue. The issue will be forwarded to the 802.11 Working Group for consideration in a future revision of the standard.