July 2014 doc.: Ieee 802. 11-14/780r2 ieee p802. 11

July 2014 doc.: IEEE 802.11-14/780r2

IEEE P802.11
Wireless LANs

802.11 LB202 some proposed resolutions for comments assigned to the author (Adrian Stephens)
Date: 2014-07-11
Author(s):
Name	Company	Address	Phone	email
Adrian Stephens	Intel Corporation			[e-mail]

Abstract
This document contains proposed resolutions to LB202 comments assigned to the author, either by name or in the capacity of TGmc technical editor.
R1 – started added resolutions of trivial technical comments.

R2 – reviewed during TGmc telecom. Got as far as CID 3681.

Comments owned by GEN or MAC

CID	Page	Clause	Comment	Proposed Change	Owning Ad-hoc
3107		Generally	There is plenty of variability of "field is" rather than "value of the field is". The job of tracking these all down and making them consistent is sisyphean. Perhaps add some definition in "word usage" that clarifies that there is no need to endlessly decorate references to values in fields.	Perhaps say in word usage: "When ‘field is' is used in contexts that relate to setting or testing the contents of a field, such as ‘The XYZ field is set to the duration of a XYZ exchange' and ‘If the XYZ field is equal to 1', the verb ‘is' should be read as ‘content of the named field is'."	GEN

Proposed Resolution:

Revised. To the end of 1.4 Word Usage, add:

“When ‘field is' is used in contexts that relate to setting or testing the contents of a field, such as ‘The XYZ field is set to …' and ‘If the XYZ field is equal to 1', these usages should be interpreted as refering to the value contained in the field.”

3088

General

The term "packet" is overloaded to mean: 1. A higher layer data entity (i.e. MSDU) 2. A physical layer protocol entity (i.e. PPDU) 3. The thing encoded by the PHY (i.e. PSDU)

Review all uses of packet. Propose that we consider uses 1 and 2 valid only. Replace all other uses with alternate terminology.

GEN

Proposed Resolution:

Revised.

At 1897.12 change “for per packet BIP processing” to “for per MMPDU BIP processing”

At 2182.26 change “several packet lengths” to “several PSDU lengths”

At 2272.30 change “AGGREGATED indicates this packet has A-MPDU aggregation.

NOT_AGGREGATED indicates this packet does not have A-MPDU aggregation” replacing “packet” by “PSDU”. Make similar changes at 2375.48.

3069

698.62

8.4.1.55

This structure is described as an element, but there is no element defined of this name. Further there is also an RLQP-element of the same name, with a different structure. Confusion reigns supreme.

Rename this from "element" to "field", but only where it refers to the non-RLQP structure.

MAC

Context:

8.4.1.55 Channel Schedule Management element The Channel Schedule Management element is transmitted in the Public Action frame or protected Public Action or protected Public Action of RLQP to indicate a channel schedule change. The format of the

Usages of “Channel Schedule Management:”

1. 
   As a parameter of SAP primitives. Note it is described there as a “set of information subfields”, which leaves the multiplicity unclear. However, the actual multiplicity is clear from the frame format
   
2. 
   As a broken format at 698.62. It’s a variable length field with no length delimiter. This is referenced from the SAP primitives as the structure that passes across the MLME SAP.
   
3. 
   As a mechanism (94.39)
   
4. 
   As an RLQP element. Although the RLQP doesn’t include this field, it does cite this field as providing a definition of its fields.
   
5. 
   As a Public Action frame. The format of this frame matches that of the RLQP element, except that the internal “Length” field is one octet, not two. And likewise doesn’t include the “Channel Schedule Measurement element”, but does cite it as providing a definition of its fields.
   

Therefore, it appears that the structure, as defined, never appears on-the-air, but is defined “for ease of reference” to the parameters included in the RLQP element and frame of the same name and related SAP primitives.

It can be removed, and the definitions of the fields moved into the Public Action frame. References to it as providing a definition of something can be replaced with a reference to the new location.
Note, I am not proposing to resolve the difference between the size of the Length fields. I assume that the authors of the Public Action frame were correct in determining a maximum length of 255 octets, and the presence of a 2-octet length field in the RLQP format is for structural consistency.
Proposed changes:

Replace the “ChannelScheduleManagment” parameter of the MLME-CHANNELSCHEDULEMANAGEMENT primitives with the following parameters:

(change “requested or provided” to “requested” in .request and indication and “provided” in .response and .confirm).

Name	Type	Valid range	Description
Reason Result Code	An enumerated value	As defined in 8.6.8.26
Channel Schedule Management Mode	An enumerated value	As defined in 8.6.8.26
Device Identification	Device Identification Information	As defined in 8.2.6.2.2	The Device Identification Information parameter indicates the regulatory identification of the STA that is requesting the schedule information.
Channel Schedule	A set of Channel Schedule Descriptors	As defined in 8.2.6.2.4	The Channel Schedule parameter indicates the channels for which the schedule information is requested or provided.

Move 699.16 to 700.33 to 1118.40 and delete the para starting “The remaining fields…” at 1118.41.

Then delete 8.4.1.55 Channel Schedule Management element
Change references to 8.4.1.55 to refer to 8.6.8.26 at: 1065.45, 1837.39, 1837.40, 1837.51, 1837.53, 1838.06, and 1838.19.

Remove reference to 8.4.1.55 at 2805.07.
Proposed resolution:

Revised. Make changes in under CID 3069. These changes remove the cited structure.

3001

805.46

8.4.21.18

The figure 8-244 contains an "Optional subelements" field, with a description "The Optional Subelements field format contains zero or more subelements, ..." But, there are no sub-elements defined for this report. As far as I can tell, subelement ID namespaces are specific to each report, so there are no possible contents for this field.

Remove field, or at least define the subelement IDs to include vendor specific.

MAC

Proposed resolution:

Revised.

Add a table defining a vendor specific subelement to 807.05, using Table 8-136 as a template, and copying text at 805.35.

3004

921.39

8.4.2.70.3

"Channel Entry fields may be grouped together" -- normative verb in clause 8, contrary to WG style.

Move to clause 10, or reword in declarative language.

GEN

Context: 921.39

Channel Entry fields may be grouped together to identify a noncontiguous channel. A noncontiguous channel is indicated by a group of N+1 Channel Entry fields where the first NChannel Entry fields contain an Operating Class field with an 80+ Behavior Limit and the last Channel Entry field in the group contains an Operating Class octet without an 80+ Behavior Limit (as defined in Annex E).

Discussion:

As the following sentence indicates how a non-contiguous channel is identified, it is appropriate to use the word “can” (equivalent in WG11 style to “is necessarily able to, given the contents of this standard”).

Proposed Resolution:

Revised. Change “may” to “can” in cited text.

3005

1029.55

8.4.2.157.2

"set the value of B2 to 1" This, IMHO, creates ambiguity, as I interpret bit labelling to be local to the structure being described.

Really the Supported Channel Width Set field is a 2-bit structure for VHT STAs or 2 1-bit structures for TVHT STAs. This should be shown graphically. One way to do this is to define a figure for the TVHT case and change the Encoding to "For a VHT STA, set to 0 if the STA does not ... The value 3 is reserved. For a TVHT STA, the field contains the and subfields as defined in Figure 8-" and add text under the figure describing the values of the and (now named) subfields. Check any references to this field from .11af text and replace with references to the named subfields.

MAC

Context (1029.38)

Proposed Changes:

At 1029.47 change the Encoding as follows:

For a non-TVHT STA: Set to 0 if the STA does not support either 160 or 80+80 MHz. Set to 1 if the STA supports 160 MHz. Set to 2 if the STA supports 160 MHz and 80+80 MHz. The value 3 is reserved. For a TVHT STA, the field is structured into subfields as defined in Figure 8-553a. For a TVHT STA, set the value of B2 the TVHT_MODE_2C Support subfield to 1 if it supports TVHT_MODE_2C; otherwise set the subfield to 0. For a TVHT STA, set the value of B3 the TVHT_MODE_2N Support subfield to 1 if it supports TVHT_MODE_2N; otherwise set the subfield to 0.

Insert the following figure before 1032.01:

	B0	B1
	TVHT_MODE_2C Support	TVHT_MODE_2N Support
Bits:	1	1

Figure 8-553a – Supported Channel Width Set field (TVHT)
Proposed Resolution:

Revised. Make changes under CID 3005 in .

3011

1045.03

8.4.2.169.1

There are a number of problems with the TBTT Information field. 1. An iteration of fields is better shown in a different way. 2. More importantly, the fields are not parseable. In each individual field, it is not possible to distinguish an unknown subelement ID from the TBTT Offset field of the next TBTT Information field. 3. Although Optional subelements are shown in figure 8-573, and described at line 60, no subelements are defined.

I think the simplest solution is to remove the Optional sublements from the TBTT Information field. Other alternatives: 1. Add the subelements field to the Neighbor AP Information field, and define at least vendor specific. 2. Modify the structure so that each TBTT Information field includes a length field, so that the individual TBTT Information fields can be parsed, and add at least a vendor specific subelement id.

MAC

Discussion:

As specified, it is broken, because the structure is not parseable. The question is whether we need to fix the structure to contain sub-elements or not. As there are currently no sub-elements defined, it would seem that the provision of sub-elements for this structure is an unnecessary complication.
Note that because the structure is currently broken, we can be sure there are no implementations of it, and therefore have complete freedom as to how to fix it. Note also that TGai modify this structure so that the TBTT Information field is fixed in length to 1 or 7 octets. The changes below are consistent with this usage.
The TBTT Information Header subfield includes a TBTT Information Count and TBTT Information Length field defined as follows: (1045.26)

The TBTT Information Count subfield is 4 bits in length and contains the number of TBTT Information fields that are included in the Neighbor AP Information field, minus one. A value of 0 indicates one TBTT Information field is present. The TBTT Information Length subfield is 1 octet in length and contains the length in octets of the TBTT Information field that is included in the Neighbor AP Information field.

These fields are only effective in creating a structure if all the TBTT Information fields are of the same length. With subelements present, this is not the case. Without subelements, one of these two fields is redundant.
However, because TGai need the ability to signal length, the fields are not redundant in their context.

The TGai version of the above text is: TGai D2.0 40.01:

The TBTT Information Count subfield contains the number of TBTT Information fields that are included in the Neighbor AP Information field. The TBTT Information Count subfield value is nonzero. The TBTT Information Length subfield contains the length in octets of each TBTT Information field included in the Neighbor AP Information field. When the value of TBTT Information Length is 1, the TBTT Information field contains the TBTT Offset subfield. When the value of TBTT Information Length is 7, the TBTT Information field contains the TBTT Offset and the BSSID subfields. Other values are reserved.

Note the (unmarked) change to the wording “the length in octets of each TBTT Information field”, which clarifies the intent of this field.

So I propose to remove the sub-elements from the TBTT Information Field and clarify the intent of the TBTT Information Length field, in a manner that anticipates TGai changes.
Proposed Changes:

Change 1044.66 as follows:

TBTT Information Header Operating Class Channel Number TBTT Information Set field #1 TBTT Information field #2 (optional) ... TBTT Information field #n (optional) Octets: 2 1 1 variable 0 or n 0 or n 0 or n Neighbor AP Information field format(11af) The format of TBTT Information Header subfield is defined in TBTT Information Header subfield.  B0 B1 B2 B3 B4 B7 B8 B15 TBTT Information Field Type Filtered Neighbor AP Reserved TBTT Information Count TBTT Information Length Bits: 2 1 1 4 8 TBTT Information Header subfield(11af)    The TBTT Information Field Type subfield is 2 bits in length and defines the structure of the TBTT Information field. Its value is 0. Values 1, 2, and 3 are reserved. The Filtered Neighbor AP subfield is 1 bit in length. It is set to 1 if the SSID of APs in this Neighbor AP Information field matches the specific SSID in the Probe Request frame. It is set to 0 otherwise. This field is valid only in the Reduced Neighbor AP Report element in a Probe Response frame and is reserved otherwise. The TBTT Information Count subfield is 4 bits in length and contains the number of TBTT Information fields that are included in the Neighbor AP Information field, minus one. A value of 0 indicates one TBTT Information field is present. The TBTT Information Length subfield is 1 octet in length and contains the length in octets of the each TBTT Information field that is included in the Neighbor AP Information field. Operating Class field is 1 octet in length and indicates the band and bandwidth of the primary channel of the APs in this Neighbor AP Information field. Valid values of Operating Class are shown in Table E-4 (Global operating classes). Channel Number field is 1 octet in length and indicates the last known primary channel of the APs in this Neighbor AP Information field. Channel Number is defined within an Operating Class as shown in Table E-4 (Global operating classes). The TBTT Information Set field contains one or more format of TBTT Information fields. The TBTT Information field is is showndefined in TBTT Information field.   TBTT Offset in TUs Optional Subelements Octets: 1 0 or n TBTT Information field(11af)   It is odd to encode the encoding of a field into its name. The TBTT Offset in TUs subfield is 1 octet in length and indicates the offset in TUs, rounded down to nearest TU, to the next TBTT of an AP from the immediately prior TBTT of the AP that transmits this element. The value 254 indicates(Ed) an offset of 254 TUs or higher. The value 255 indicates(Ed) an unknown offset value. Subelements are specific to the element in which they are defined. Which element defines these sub-elements? Are there any defined for that element? The Optional Subelements field(Ed) contains zero or more subelements, each consisting of a 1-octet Subelement ID field, a 1-octet Length field, and a variable-length Data field, as shown in Error: Reference source not found. Any optional subelements are ordered by nondecreasing Subelement ID.

Proposed Resolution:

Revised. Make changes under CID 3011 in . These changes remove subelements from the field.

3013

1063.13

8.4.2.1

"... the format of the Information field follows the format of the vendor specific element in 8.4.2.25 (Vendor Specific element)." -- "follows the format" is ambiguous. Does it include a redundant ID and length field or not?

Be more specific. Something like, "has the format of the Vendor Specific element, omitting the Element ID and Length fields".

MAC

Context: 1063.12

The RLQP-elements are shown in Table 8-266 (RLQP-element definitions). Info ID 56 797 stands for Vendor Specific information. When the Info ID is equal to 56 797, the format of the Information field follows the format of the vendor specific element in 8.4.2.25 (Vendor Specific element).

Discussion:

The Vendor-specific RLQP-element is not exactly the same as the Vendor Specific element because the length and Info ID fields are 2 octets, rather than 1 octet.

The simplest way to resolve this is to define the structure here.

At the cited location, delete the sentence “When the Info ID is equal to 56 797 … vendor specific element in 8.4.2.25.”

At 1063.33 in the “RLQP-element (subclause)” column, change reference from 8.4.2.25 to 8.4.5.5.

Insert the following subclause:

8.4.5.5 Vendor Specific RLQP-element. The Vendor Specific RLQP-element is used tocarry information not defined in this standard within a single defined format, so that reserved Info IDs are not usurped for nonstandard purposes and so that interoperability is more easily achieved in the presence of nonstandard information. The RLQP-element is in the format shown in Figure 8-xxx (Vendor Specific RLQP-element format). Info ID Length Organization Identifier Vendor-specific content Octets: 2 2 j n-j Figure 8-xxx -- Vendor Specific RLQP-element format The Info ID and Length fields are defined in 8.4.5.1. The first 3 or more octets of the Information field identify the entity that has defined the content of the particular Vendor Specific RLQP-element. The length of the Organization Identifier field (see 8.4.1.31 (Organization Identifier field)) is j octets, and the order of this field is described in 8.2.2 (Conventions). The value of the Length field (n) is constrained by n >= j. The length of the vendor-specific content is n–j octets.

Proposed Resolution:

Revised. Make changes under CID 3013 in . These changes explicitly define the format of the Vendor Specific RLQP-element.

3024

1294.10

9.11

"and the negotiated header shall be added by the peer MAC" -- this is a normative requirement for "someone else".

Express it in terms of what the current MAC entity shall do.

MAC

Context: 1294.04

A STA can use the U-PID element transmitted in ADDTS Request and ADDTS Response frames to indicate the protocol responsible for handling MSDUs corresponding to the TID indicated within the frame carrying the U-PID element (see 10.4.4.4 (TS setup procedures for both AP and non-AP STA initiation)). Following a successful negotiation through an ADDTS exchange that included a U-PID element with the No-LLC field equal to 1, before transmission the MAC shall strip the LLC header from all MSDUs corresponding to the TID indicated in the ADDTS exchange and the negotiated header shall be added by the peer MAC before delivery at the peer MAC-SAP.

Proposed change:

Revised.
At cited location delete: “and the negotiated header shall be added by the peer MAC before delivery at the peer MAC-SAP”.

At the end of the cited para add:
“A STA that participates in a successful ADDTS exchange that included a U-PID element with the No-LLC field equal to 1 and that receives an MSDU corresponding to the TID indicated in the ADDTS exchange shall add the header indicated by the U-PID element before delivery of the MSDU at the MAC-SAP.”
And to maintain uniformity, make the following stylistic change:

“Following a successful negotiation through an ADDTS exchange that included a U-PID element with the No-LLC field equal to 1, before transmission the MAC shall strip the LLC header from all MSDUs corresponding to the TID indicated in the ADDTS exchange.”

to read:

“A STA that participates in a successful ADDTS exchange that included a U-PID element with the No-LLC field equal to 1 shall strip the LLC header from an MSDU corresponding to the TID indicated in the ADDTS exchange before transmission of the MSDU.”