July 2011 doc.: IEEE 802.11-11/0940r1

IEEE P802.11
Wireless LANs

LB171 Some MLME, MIB and General Comments
Date: 2011-07-10
Author(s):
Name / Affiliation / Address / Phone / email
Peter Ecclesine / Cisco Systems / 170 W. Tasman Dr.,MS SJ-14-4, San Jose, CA 95134-1706 / +1-408-527-0815 /


Interpretation of a Motion to Adopt

A motion to approve this submission means that the editing instructions and any changed or added material are actioned in the TGaf Draft. This introduction is not part of the adopted material.

Editing instructions formatted like this are intended to be copied into the TGaf Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents).

TGaf Editor: Editing instructions preceded by “TGaf Editor” are instructions to the TGaf editor to modify existing material in the TGaf draft. As a result of adopting the changes, the TGaf editor will execute the instructions rather than copy them to the TGaf Draft.

MLME comments

LB 171 CID 28:

28 / 2.53 / Clause 8.3.3.10 (pg 26, L62) adds four IEs to probe request. This means you need to modify MLME-SCAN.confirm (cl 6.3.3.3) to add them to the "BSSDescriptionSet" table. / As in comment

Discussion:

LB 171 CID 28 asks the the addition of four IEs to MLME-SCAN.confirm, to return any of the four IEs added by the amendment.

Propose Accepted for CID 28, per discussion and editing instructions in 11-11/0940r1.

LB 171 CID 639:

639 / 2.53-24 / The service primatives defined in this section are inapproriate and conatin functionality that is duplicative. Serveral primatie provide similar redundant mechanisms. / Remove all current text in section 6.3 Rewrite as reuse of existing mechanisms (like join or scan)

Discussion:

LB 171 CID 639 asks the replacement of all text modifying 6.3 MLME SAP interface, asserting no new service primitatives are needed, and several provide similar redundant mechanisms. The comment also asks that any changes be provided as modifications to existing primitives. We disagree that existing primitives can be modified to provide the function of the Contact Verification Signal.

Propose Rejected for CID 639 - We disagree that existing primitives can be modified to provide the function of the Contact Verification Signal.

LB 171 CID 640:

640 / 2.53 / Section 6.3 creates new service rpimatives for nearly every new frame defined in the rest of the speccification. This is a porr and clumsy design that does not reuse the existing higher level MLME primatives. Joinging a White Space network should not be that different from joinging any other BSS from the MLME perspective. Different errors will be required. Scanning should be modified to include additional WS related information. Service primatives are most intersting where they apply to a state machine. No state machine is should for new states so until there are such new states there should be no significant new MLME messages / Remove all current text in section 6.3 Rewrite as reuse of existing mechanisms (like join or scan)

Discussion:

LB 171 CID 640 asks the replacement of all text modifying 6.3 MLME SAP interface, asserting no new service primitatives are needed, the existing scan and join should suffice for finding and joining a BSS. The comment asks that any changes be provided as modifications to existing primitives. We do not modify the join process, and disagree that the White Space Map, Network Channel Control, Channel Schedule Management could use existing higher level MLME primitives. We disagree that existing primitives can be modified to provide the function of the Contact Verification Signal.

Propose Rejected for CID 640 - We disagree that the White Space Map, Network Channel Control, Channel Schedule Management could use existing higher level MLME primitives. We disagree that existing primitives can be modified to provide the function of the Contact Verification Signal.

General comments

LB171 CID 329, 516:

329 / General / As per the FCC's final rules, the Mode II or Fixed device must validate the FCC ID of a Mode I device with database before it can provide its list of available channels. This requirement is not covered in the current specification. / See comment
516 / General / As per the FCC's final rules, the Mode II or Fixed device must validate the FCC ID of a Mode I device with database before it can provide its list of available channels. This requirement is not covered in the current specification. / As per the comment.

Discussion:

LB 171 CIDs 329 and 516 says the current specification does not provide a means to validate the FCC ID of a Mode I device. P802.11af D1.0 page 135 defines Device Indentification Information that in the USA includes the FCC ID, and is used in Channel Availability Query. Note the 802.11 WG has removed all normative references to specific regulatory requirements from the standard.

Propose Rejected for CIDs 329 and 516 with explanation that Channel Availability Query provides a means for a STA to provide its Device Identification Information and be validated by geolocation database control. Note the 802.11 WG has removed all normative references to specific regulatory requirements from the standard.

LB171 CID 517:

517 / General / As per the FCC's final rules, the Mode II must signal to Mode I when it goes active from power off. It may be also necessary when its available channel map changes. There are no mechanisms to do so in current specification. / Include the mechanism as required by FCC rules.

Discussion:

LB 171 CID 517 says the current specification does not provide a means to signal channel map changes to a Mode I device. P802.11af D1.0 page 65 line 8 defines the procedure to signal Mode 1 devices that the White Space Map has changed. Note the 802.11 WG has removed all normative references to specific regulatory requirements from the standard.

Propose Rejected for CID 517 because P802.11af D1.0 page 65 line 8 defines the procedure to signal Mode 1 devices that the White Space Map has changed. Note the 802.11 WG has removed all normative references to specific regulatory requirements from the standard.

LB171 CID 519:

519 / General / Fixed STA needs to broadcast their identity and location information while operating in TVWS band as per the FCC's rules. Also, the registration of such devices to database is not covered. / As per the comment

Discussion:

LB 171 CID 519 says the current specification does not provide a means to signal identity and location information. P802.11af D1.0 page 131 line 57 sets dot11LCIDSERequired to true, and by DSE procedures (10.12.3 REVmb D9.0 page 1059), enabling STAs and dependent APs signal the DSE Registered Location element containing their identity and location information. Note the 802.11 WG has removed all normative references to specific regulatory requirements from the standard.

Propose Rejected for CID 519 because P802.11af D1.0 page 131 line 57 sets dot11LCIDSERequired to true, and by DSE procedures (10.12.3 REVmb D9.0 page 1059), enabling STAs and dependent APs signal the DSE Registered Location element containing their identity and location information. Note the 802.11 WG has removed all normative references to specific regulatory requirements from the standard.

LB171 CID 942:

942 / General / In TV Whtiespace, Mesh Point (maybe Mode II device) shall access the geo-location database for obtaining an available channel list. IEEE 802.11s shall provide the channel availability query procedure. / Provide channel availability query procedure in IEEE 802.11s.

Discussion:

LB 171 CID 942 says the current specification does not provide a means to operate 802.11s mesh networks in TVWS. It may be required that any STA transmitting Channel Switch Request is operating under control of Geolocation database. How that satisifies regulatory requirements is not specified in the standard. It is not a requirement of the TGaf PAR to support all options of REVmb in TVWS. Note the 802.11 WG has removed all normative references to specific regulatory requirements from the standard.

Propose Rejected for CID 942 because it is not required to support all 802.11 options in TVWS. Note the 802.11 WG has removed all normative references to specific regulatory requirements from the standard.

LB171 CIDs 592 and 943:

592 / General / According to 8.5.13 and 10.22 in 802.11REVmb, TDLS channel switch to TV Whitespace is not supported. In order to enable direct link on TV whitespace channels, TDLS channel switch mechnism should be revised. / Specify.
See forthcoming document 11-11/xxxxr0.
943 / General / In order to use TDLS Off-channel, a non-AP STA shall access the geo-location database before transmitting Channel Switch Request frame.
Also, the non-AP STA shall provide the white space map to a peer STA. / Provide the TDLS Off-channel behavior in TV Whitespace.

Discussion:

LB 171 CIDs 592 and 943 say the current specification does not provide a means to operate Direct Links in TVWS. It may be required that any STA transmitting Channel Switch Request is operating under control of Geolocation database. How that satisifies regulatory requirements is not specified in the standard. It is not a requirement of the TGaf PAR to support all options of REVmb in TVWS. Note the 802.11 WG has removed all normative references to specific regulatory requirements from the standard.

Propose Rejected for CIDs 592 and 943 because it is not required to support all 802.11 options in TVWS. Note the 802.11 WG has removed all normative references to specific regulatory requirements from the standard.

LB171 CID 653:

653 / 3.1 / In the normative text, Registered location security server (RLSS) is used to emphasis the secury requirement of the server. The definition is missing here. / Define it

Discussion:

LB 171 CID 653 asks for a definition of the registered location secure server.

Propose Accepted for CID 653, per discussion and editing instructions in 11-11/0940r1.

LB171 CID 336:

336 / 26.60 / If there is a Supported Operating Classes element in the Beacon, shouldn't there be one in the Probe Response? / Add a Supported Operating Classes element to the Probe Response frame body, Table 8-26 if required.

Discussion:

LB 171 CID 336 asks if Probe Response should be changed to include Supported Operating Classes element. The Supported Operating Classes text in Probe Response should be changed to add “or dot11ChannelPowerManagementActivated is true”.

Propose Accepted for CID 336, per discussion and editing instructions in 11-11/940r1. The Supported Operating Classes text in Probe Response should be changed to insert “or dot11ChannelPowerManagementActivated” is true

LB171 CID 1059:

1059 / 27.43 / I believe the default for any new element should be extensible=<non-blank>. Non-extensible elements are supported for legacy compatibility. / Change extensible to Yes for Geodatabase Inband Enabling Signal

Discussion:

LB 171 CID 1059 asks Geodatabase Inband Enabling Signal should be changed to be extensible, and as it has a length element, it can be made extensible.

Propose Accepted for CID 1059, per discussion and editing instructions in 11-11/0940r1.

LB171 CID 378:

378 / 131.13 / Text states that additional requirements are amended to the definitions, which are described in clause 3… I see additional acronyms and definitions in clause 3, but I don't see additional requirements in clause 3. / Either add the requirements or change the sentence so that it doesn't indicate that some requirements are in clause 3. Maybe I'm just mis interpretting the sentence. If yes then suggest clarification. The requirements might be the text later in this annex.

Discussion:

LB 171 CID 378 asks to clearly state what new requirements are or change the sentence. We propose to delete the sentence and resolve both CIDs 378 and 1154 with the deletion.

Propose Revised for CID 378, per discussion and editing instructions in 11-11/0940r1.

LB171 CID 514:

514 / 132.06 / The paragraphs here clarify behavior while using certain frames like DSE measurement report, channel power management announcement etc. It will be better to create sub-clauses for each specific information. / as per the comment

Discussion:

LB 171 CID 514 observes that a paragraph has unrelated “may”, “should” and “can” statements, and states they should be separated.

Propose Revised for CID 514, per discussion and editing instructions in 11-11/0940r1.

MIBs comments

LB171 CID 1148:

1148 / 111.06 / These enumeration tags must follow ASN.1 syntax. Embedded slashes and spaces are not allowed. / convert to valid ASN.1 names

Discussion:

LB 171 CID 1148 asks that dot11WSSTAType enumeration be converted from “personal/portable” to valid ASN.1 names like “GDC”. SYNTAX INTEGER {GDCAP(1), GDCNonAPSTA(2), GDCFixedSTA(3), reserved(4) }

Propose Accepted for CID 1148, per discussion and editing instructions in 11-11/0940r1.

LB171 CID 1150:

1150 / 120.06 / Invalid use of INTEGER in a non-enumeration context / Either change this to an Unsigned32, or define is to be an enumeration with wgs84(1), nad83_navd88(2), nad83_mlwvd(3) as tags

Discussion:

LB 171 CID 1150 asks that dot11STALCIDatum enumeration be converted from INTEGER to valid ASN.1 names like REVmb D9.0 page 2155 line 49 INTEGER { wgs84 (1), nad83navd88 (2), nad93mllwvd (3) }.

Propose Accepted for CID 1150, per discussion and editing instructions in 11-11/0940r1.

LB171 CID 1279:

1279 / 103.00 / parameter dot11DatabaseControlActivated not defined

Discussion:

LB 171 CID 1279 asks that dot11DatabaseControlActivated be defined. We modify the name to GDCActivated to reflect operation under control of an authorized geolocation database.

Propose Revised for CID 1279, per discussion and editing instructions in 11-11/0940r1.

LB 171 CIDs 1280 and 1281:

1280 / 103.00 / dot11ExtendedChannelSwitchActivated is not defined in MIB.
1281 / 103.00 / dot11OperatingClassesRequired is not defined in MIB.

Discussion:

CIDs 1280 and 1281 ask that existing REV mb Draft 9.0 items (dot11ExtendedChannelSwitchActivated on page 1847 line 48, dot11OperatingClassesRequired on page 1833 line 45) be defined in the amendment

Propose Rejected for CIDs 1280 and 1281 as they refer to existing REV mb Draft 9.0 items (dot11ExtendedChannelSwitchActivated on page 1847 line 48, dot11OperatingClassesRequired on page 1833 line 45).

Proposed Resolution:

Accept changes to P802.11af draft based on discussion and editing instructions in 11-11/0940r1: