May 2001doc.: IEEE 802.11-01/262r2
IEEE P802.11
Wireless LANs
802.11e Draft Standard D1.0 Letter Ballot 27 Comments, Clause 5
Date:June 11, 2001
Revision 0: Comments from ballots received through morning of May 14, 2001.
Revision 2: Incorporate comments from ballots received between May 14 and close of LB27.
Author:John Fakatselis, Chair, Et Al
5 / JohnCoffey / T / Yes, it’s a part of the “No” / Page 7 has 3 refs to “clause 19”; I can’t find this clause. The phrase “placeholder” appeared several times. The document appears to be materially under-specified in ways that may be important. / Filling in the gaps noted.5 / Matthew Fischer / T / Y / The note in this section of the draft bothers me. It says that {generic} management frames are class 3, but then the note says that some may be class 1 or 2, but declines to identify those frames. The only thing that an implementation may currently do is declare all to be class3, and when a class 2 is required, it will be rejected. / Create a comprehensive list of the classification of all possible generic management frames.
5 / Myles / T / Yes / The description of the 802.11 architecture was confused in the original standard. The addition of QoS concepts has only made the description more obscure / A complete rewrite is required of Chapter 5 and the corresponding definitions in Chapter 3. Well drawn architectural diagrams are also required
5 / Myles / T / Yes / The text does not address operation in an IBSS (as is acknowledged in the note) and so it is not possible to evaluate it / Include appropriate text for an IBSS
5 / Myles / T / Yes / If one accepts that Containers are a good idea, why shouldn’t they be available in an IBSS? / Clarify, although I would prefer to get rid of containers
5 / RAJU GUBBI / T / Y / The note in this section of the draft bothers me. It says that {generic} management frames are class 3, but then the note says that some may be class 1 or 2, but declines to identify those frames. The only thing that an implementation may currently do is declare all to be class3, and when a class 2 is required, it will be rejected. / Create a comprehensive list of the classification of all possible generic management frames.
5 c) 1) Ii) / Matthew Fischer / T / Y / Class 3 frame type:
QoS data subtypes allowed to/from ESTA when associated with EAP.
Not clear what this means. If it means that QOS data types can be passed among ESTA which are members of the same BSS, but neither is the EAP, then how does either of the ESTA know that the other is actually associated with the EAP as is required in the language just cited?
5 c) 1) Ii) / RAJU GUBBI / T / Y / Class 3 frame type:
QoS data subtypes allowed to/from ESTA when associated with EAP.
Not clear what this means. If it means that QOS data types can be passed among ESTA which are members of the same BSS, but neither is the EAP, then how does either of the ESTA know that the other is actually associated with the EAP as is required in the language just cited?
5. ? / Amar Ghori / E / YES / p.9 line 28, this is out of outline order – maybe this is supposed to be 5.5
Since RR can be sent at any time instead of only in response to a CC frame, CC as a separate frame should be elimintated / Fix outlining
Eliminate iv) Contention Control (CC)
5.1.1.4 / Bob O’Hara / T / Y / You are darn right that the draft proposes methods that are “non-traditional”! Other LANs have not tried to shoe-horn complex functions into their MAC to support QoS. Yet, they seem to manage well. They have simply waited for the technology to mature to the point that the simplest solution to providing QoS, enough bandwidth, became available. If higher layers must be “WLAN-aware”, as is stated here, the QoS mechanisms that require this awareness will be used infrequently (if ever) in any but products serving dedicated applications. / Delete all QoS mechanisms from the draft that require that higher layers be “WLAN-aware”.
5.2 / Kenji Fujisawa / T / Yes / Page 7 refers “clause 19”, but it is missing.
5.2.2.2 / t / YES / Reference to Clause 19, but no text is provided for Clause 19. / Remove reference or provide text for Clause 19.
5.2.2.2 / Amar Ghori / T / YES / Current understanding is that the QoS enhancements are mandatory, not optional, and that there is now only one uniform level and not several strictly nexted levels of QoS enhancements / Indicate QoS enhancements mandatory, indicate single qoS level adhered to by stations
5.2.2.2
5.2.3
5.2.4
5.4.1.3 / Diepstraten / T /
Y
/ There are several references for further descriptions to Clause 19, which does not exist in the current draft. / Provide the Clause 19 material to address the referenced subjects.5.2.2.2 / Greg Parks / T / YES / Current understanding is that the QoS enhancements are mandatory, not optional, and that there is now only one uniform level and not several strictly nexted levels of QoS enhancements / Indicate QoS enhancements mandatory, indicate single qoS level adhered to by stations
5.2.2.2 / Gunnar Rydnell / T / Yes / ‘The QoS enhancements are available to an ESTA associated in an QBSS, at a level negotiated between the ESTA and the EAP of the QBSS at the time the ESTA’s association is established’.
The negotiation is not described, and Association Request does not contain QoS level info. / Describe negotiation procedure and update MMPDUs.
5.2.2.2 / Harry Worstell / T / YES / Where is Clause 19? / Add Clause 19.
5.2.2.2 / Ken Kimura / T / YES / Current understanding is that the QoS enhancements are mandatory, not optional, and that there is now only one uniform level and not several strictly next levels of QoS enhancements / Indicate QoS enhancements mandatory, indicate single QoS level adhered to by stations
5.2.2.2
5.2.3
5.2.4
5.4.1.3 / Letanche / T / Y / References are made to a non-existent clause 19. / Add clause 19.
5.2.2.2 / Matthew Fischer / T / Y / Where is clause 19?
5.2.2.2 / Matthew Sherman / T / YES / Where is Clause 19? / Add Clause 19.
5.2.2.2
5.2.3
5.2.4
5.4.1.3 / Myles / T / Yes / Unable to evaluate properly because text refers to Clause 19, which is not available / Include Clause 19 in ballot document
5.2.2.2 / RAJU GUBBI / T / Y / Where is clause 19?
5.2.2.2 / Ryoji Kido / T / YES / Current understanding is that the QoS enhancements are mandatory, not optional, and that there is now only one uniform level and not several strictly nexted levels of QoS enhancements / Indicate QoS enhancements mandatory, indicate single qoS level adhered to by stations
5.2.2.2 / Simon Black / T / There is a reference to clause 19 here but there seems to be no such clause (and lots of missing detail regarding the actual QoS protocol) / Finish the draft before sending out for the next ballot.
5.2.2.2
p7 l21 / Skell / T / Yes / This and other sections refer to Clause 19. / What is Clause 19?
5.2.2.2 / Steve Gray / T / Y / There is a reference to clause 19 here but there seems to be no such clause (and lots of missing detail regarding the actual QoS protocol) / Finish the draft before sending out for the next ballot.
5.2.2.2 5.2.3 5.2.4 3.58 / Bill McFarland / T / no / These clauses reference non-existent Clause 19 and QoS “levels”. The QoS level distinction was eliminated by consensus. / Remove the sentences or phrases in each of these clauses, and any other clauses, that reference non-existent Clause 19 or QoS “levels”.
5.2.2.2, 5.2.3, 5.2.4,
5.4.1.3 / Dima / T / yes / Text refers to Clause 19 that is not a part of the draft
5.2.2.2,
5.2.3,
5.2.4,
5.2.5,
Annex F / Fischer,Michael / T / no / References to clause 19 are obsolete, as the plan from last October to group much of the new, QoS-related material in a new clause was not done in the QoS baseline ad-hoc document and the various EDCF, HCF, and FEC proposal documents which provided most of the new text that appears in D1.0.
It no longer appears that a new clause will be needed to present QoS-related normative material. However, there is considerable need for an informative explanation of the QoS architecture, and examples of possible and/or recommended interaction with higher-layer, QoS management entities, in greater detail than is practical in clause 5. The informative sub-clauses in the enhanced security draft are an example of this type of material relating to the security algorithms and interactions with higher layer authentication entities, and in the opinion of this commenter add to the understandability of the security draft.
Also, TGe is already being asked (informally) by other task groups, including some from 802.15 and 802.16, for more explanatory material about the architecture and intended interaction with higher layers. This suggests strongly that it would be unwise to release a draft for sponsor ballot without such material. / Remove the references to clause 19 and place any required normative material into clauses 6, 7, 9, 10, and 11 as appropriate. Add the architectural and other descriptive material to Annex F, making this annex an informative description of the QoS facility and one or more illustrative usage scenarios.
This commenter plans to submit material that may be suitable for some of the introductory and overview portions of Annex F at the July meeting. It is expected that descriptive material on usage scenarios will be available in, or can be generated based on, the submissions needed to complete the normative definition of the "signaling" mechanism required to fill gaps in other clauses and identified in other comments by this commenter.
5.2.2.2,
5.2.3,
5.2.4,
5.2.5,
Annex F / Fischer,Michael / T / no / References to clause 19 are obsolete, as the plan from last October to group much of the new, QoS-related material in a new clause was not done in the QoS baseline ad-hoc document and the various EDCF, HCF, and FEC proposal documents which provided most of the new text that appears in D1.0.
It no longer appears that a new clause will be needed to present QoS-related normative material. However, there is considerable need for an informative explanation of the QoS architecture, and examples of possible and/or recommended interaction with higher-layer, QoS management entities, in greater detail than is practical in clause 5. The informative sub-clauses in the enhanced security draft are an example of this type of material relating to the security algorithms and interactions with higher layer authentication entities, and in the opinion of this commenter add to the understandability of the security draft.
Also, TGe is already being asked (informally) by other task groups, including some from 802.15 and 802.16, for more explanatory material about the architecture and intended interaction with higher layers. This suggests strongly that it would be unwise to release a draft for sponsor ballot without such material. / Remove the references to clause 19 and place any required normative material into clauses 6, 7, 9, 10, and 11 as appropriate. Add the architectural and other descriptive material to Annex F, making this annex an informative description of the QoS facility and one or more illustrative usage scenarios.
This commenter plans to submit material that may be suitable for some of the introductory and overview portions of Annex F at the July meeting. It is expected that descriptive material on usage scenarios will be available in, or can be generated based on, the submissions needed to complete the normative definition of the "signaling" mechanism required to fill gaps in other clauses and identified in other comments by this commenter.
5.2.3 / Bob O’Hara / T / Y / This definition claims that more information , presumably the normative requirements, are described in clause 19. There is no clause 19 in the document.
5.2.3 / Matthew Fischer / T / Y / Where is clause 19?
5.2.3 / RAJU GUBBI / T / Y / Where is clause 19?
5.2.3 / Yossi Texerman / T / Yes / “Additional information about wireless repeaters appears in clause 19.”
Clause 19 does not appear in this draft. / Provide the necessary specification for wireless repeaters or else remove all references to this concept from text.
5.2.3,
5.4.1.1,
3.65, 4 / Fischer,Michael / T / no / The "repeater" mentioned in 5.2.3 and the "remote hybrid coordinator" mentioned in 5.4.1.1, 3.65, and 4 appear to be overlapping concepts for a single function, and should not be treated as separate. It does not seem that two, independent mechanisms are needed.
Furthermore, it seems much more appropriate, especially for clause 5, but possibly for TGe-QoS as a whole, to specify a more general repeater concept, replacing both the special case listed in 5.2.3 (which is probably possible under the 1999 standard, although I am not aware of anybody trying to implement such), and the RHC, described in 5.4.1.1, which appears to be an over-constrained special case, rather than a fundamental element of distribution service.
If the RHC is coordinator of a QBSS connected by a WDS link to another QBSS to form an ESS, the only thing being mentioned in the added text of 5.4.1.1 that is really new is a means within 802.11 to activate a WDS link. This could be defined as part of QoS signaling without creating new terms and new architectural concepts. Adding concepts of questionable necessity and undetermined side effects, such as "subsidiary BSS" and "remote coordinator" complicate both the effort required to write the QoS standard and the effort required by others to read, understand, and implement the QoS standard. / Remove the definitions of "remote hybrid coordinator" and "RHC."
Remove the statement that a repeater is the AP of a secondary BSS while being associated as a station in the primary BSS. (BTW, if this change is not made it is unclear how the To/FromDS bits should be set in frames between the "secondary AP" and "primary AP").
Appropriate text for 5.2.3:
The spatial coverage of a BSS is limited, often due to attenuation by intervening structural materials, in ways that cause undesirable discontinuities of LAN connectivity. In certain cases this can be overcome using a wireless repeater. A STA may be preconfigured to provide wireless repeater functionality. When activated, the repeater STA becomes the AP of a new BSS in the same ESS, and distribution services at the repeater communicate with the infrastructure via a wireless distribution system link to the AP of the BSS for which spatial coverage is being extended.
Appropriate text for 5.4.1.1:
While IEEE 802.11 does not specify DS implementations, it does recognize and support the use of the WM as the DSM. This is specifically supported by the IEEE 802.11 frame formats. (Refer to Clause 7 for details.) and by the wireless repeater function.
5.2.4 / Harry Worstell / T / YES / A portal only connects to a DS. However, there might be multiple independent LAN’s that connect to 802.11 LANs. Would each have a separate DS? 5.3.2 states that a Bridge Portal does not connect to a DS. Rather it provides one “DS” service – the integration service. These statements seem in conflict. / Clarify.
5.2.4 / Liwen wu / NO vote / Page7,Line36: Clause 19 is missing / Define clause 19
5.2.4 / Matthew Fischer / T / Y / Can’t I have a bridge portal which also connects to another 802.11E LAN? The repeater function mentioned in 5.2.3 seems to be the only mechanism for doing this, yet that is a repeater, not an intelligent forwarding device.
5.2.4 / Matthew Sherman / T / YES / A portal only connects to a DS. However, there might be multiple independent LAN’s that connect to 802.11 LANs. Would each have a separate DS? 5.3.2 states that a Bridge Portal does not connect to a DS. Rather it provides one “DS” service – the integration service. These statements seem in conflict. / Clarify.
5.2.4 / RAJU GUBBI / T / Y / Can’t I have a bridge portal which also connects to another 802.11E LAN? The repeater function mentioned in 5.2.3 seems to be the only mechanism for doing this, yet that is a repeater, not an intelligent forwarding device.
5.2.4 / Spiess / T / Y / Reference to Nonexistant text in clause 19 / Clause 19 must describe BPs.
5.2.4 / Yossi Texerman / T / Yes / “Additional information about bridge portals appears in clause 19.”
Clause 19 does not appear in this draft. / Provide the necessary specification for bridge portals or else remove all references to this concept from text.
5.2.4,
5.4.1.2,
3.52 / Fischer,Michael / T / no / The Bridge Portal is both a poor term for the underlying concept and could lead to confusion because the same term is used to mean something similar, but not identical, in HIPERLAN/2 specifications. Furthermore, in this draft the term is over-defined and under-specified.
The key concept that needs both a name and a means for activation is an entity that provides integration service but is not co-located with the distribution services entity of the BSS. (The locus of distribution services for a BSS is, by definition, the AP of that BSS). / Remove the references to 802.1 bridge specifications from the definition and attempt to find a better name for the actual integration concept.
As part of the definition of QoS signaling, provide a message (probably a pair of QoS Management Action request/response frames) and the corresponding MLME primitives to direct traffic for a particular TC at a particular ESTA over a WDS link between that ESTA and a "BP". Using these primitives, a higher-layer QoS management entity that knows or determines the existence of a more direct path for traffic belonging to a given TC can improve service and reduce load on the WM by enabling direct transfer of frames that would otherwise have to be retransmitted by the HC, hence traverse the WM twice. Two action messages are needed because information exchange is needed between distribution services and the ESTA to convey the address of the "BP," and between either the ESTA or distribution services (depending on how connection signaling is initiated, I prefer the ESTA to initiate) and the "BP" to convey the TSpec of this TC.
5.2.5 / Amar Ghori / T / YES / There is no Annex F in this draft, so I reserve comment / To be reviewed when Annex F is available
5.2.5 / Greg Parks / T / YES / There is no Annex F in this draft, so I reserve comment / To be reviewed when Annex F is available
5.2.5 / Ken Kimura / T / YES / There is no Annex F in this draft, so I reserve comment / To be reviewed when Annex F is available
5.2.5 / Kenji Fujisawa / T / Yes / Page 8 line 3 refers “Annex F”, but it is missing.
5.3 / Amar Ghori / T / YES / It seems this should include some reference to QoS traffic specification as well as scheduling / Add traffic specification
5.3 / Greg Parks / T / YES / It seems this should include some reference to QoS traffic specification as well as scheduling / Add traffic specification
5.3 / Ken Kimura / T / YES / It seems this should include some reference to QoS traffic specification as well as scheduling / Add traffic specification
5.3 / Ryoji Kido / T / YES / It seems this should include some reference to QoS traffic specification as well as scheduling / Add traffic specification
5.3.1 / Amar Ghori / T / YES / It seems this should include some reference to QoS traffic specification as well as scheduling / Add traffic specification