March 2016 doc.: IEEE 802.11-16/273r4

IEEE P802.11
Wireless LANs

802.11
REVmc Sponsor first recirculation ballot (SB1) - some proposed comments resolutions (Stephens) – Part 3
Date: 2016-03-15
Author(s):
Name / Company / Address / Phone / email
Adrian Stephens / Intel Corporation /

Comments Pending Resolution

Assigned Comments

CID / Page / Clause / Comment / Proposed Change / Owning Ad-hoc / Comment Group /
7811 / 11.31 / 3.1 / Distribution service versus distribution system service? / Change "distribution service" to "distribution system service" at P11.31, and P99.29. / GEN / Definitions

Discussion:

The “DS” stands for distribution system, not distribution service.

The DS is a service accessed via a SAP.

In the same way that the MAC provides a service.

Context: 11.30:

distribution system access function (DSAF):A function within an access point (AP) or mesh gate that
uses the medium access control (MAC) service and distribution system service (DSS) to provide access between the distribution system (DS) and the wireless medium (WM).

Context: 99.26:

Refer to the ESS in Figure 4-15 (IEEE Std 802.11 Infrastructure model) and consider an MSDU being sent from STA 1 to STA 4. One or more frames containing the MSDU are sent from STA 1 and received by STA 2 (the “input” AP). The AP gives a MAC service tuple containing the MSDU to the distribution service of the DSDSS.

Proposed Resolution:

Revised.

At 11.31 change “distribution service” to “distribution system service (DSS)”

At 99.29 change “distribution service of the DS” to “DSS”.

7151 / 14.50 / 3.1 / "provide access to one or more distribution systems, via the wireless medium" -- the mesh gate must surely provide access to a DS locally, not via the wireless medium / Add that it provides access to a single DS locally. / GEN / Definitions

Context: 15.49:

mesh gate:Any entity that has a mesh station (STA) function and a distribution system access function
(DSAF) to provide access to one or more distribution systems, via the wireless medium (WM) for the mesh basic service set (MBSS).

Discussion: where do these >1 distribution systems come from? The diagram shown in Figure 5-6 of D5.2 shows a single distribution system attached to the mesh gate.

Yes, the mesh gate might transmit data to another mesh gate, and that data might travel over a different DS attached to that mesh gate. This this what “provide access” means? I think not.

Whether the DS is implemented using a wireless or wired link is not relevant, and not visible to the mesh gate logical entity.

Status update: Mark H agrees that the presence of multiple DSs per MBSS is described elsewhere, so the following change loses nothing.

Proposed resolution:

Revised. At cited location replace “access to one or more distribution systems, via the wireless medium (WM)” with “access to a single distribution system”.

7750 / 880.10 / 9.4.2.45 / There are 4 instances of "capability enabled" / Change at least the first 3 to "Capability Enabled". I'm not sure what " STAs that have the Beacon request capability enabled" in 11.28.1 is referring to / MAC / Editorials

Discussion:

Is the generation of a Beacon report mandatory if you support RM?

2774.27 indicates it is.

However, there are a set of Beacon measurement options:

  • Beacon Passive Measurement Capability Enabled
  • Beacon Active Measurement Capability Enabled
  • Beacon Table Measurement Capability Enabled
  • Beacon Measurement Reporting Conditions Capability Enabled

So “Beacon request capability enabled” at 1829.57 is, of itself, not good enough.

At 1829.52 there is:

These frames are received directly or via associated STAs that support the Beacon request capability (as indicated by the Beacon Passive Measurement Capability Enabled bit or the Beacon Active Measurement Capability Enabled bit being set in the RM Enabled Capabilities element in the (Re)Association frame).

Which locally defines “support for the Beacon request capability”.

We can then change the problematic use as follows:

1829.56:

An AP might scan other channels as part of its channel selection process or might request associated STAs that have support the Beacon request capability enabled to perform an offchannel Beacon request measurement, and these procedures might provideQLoad Report elements received from APs operating on other channels.

Proposed resolution:

Revised.

At 880.10, 880.08, 1761.53 change “capability enabled” to “Capability Enabled”.

At 1829.25 change “that have the Beacon request capability enabled” to “that support the Beacon request capability”

7685 / 1055.12 / 9.4.2.159 / It says "The maximum value of theRXVECTOR parameter MCSof a PPDU" / Change to "This parameter" / EDITOR / Frame Formats

Discussion:

A similar comment has already been resolved as follows:

7686 / 1056.13 / 9.4.2.159 / It says "The maximum value of theTXVECTOR parameter MCSof a PPDU" / Change to "This parameter" / EDITOR
Proposed Rewording of definition: at 1056.06 in the “definition” column.
If transmitted by a STA in which dot11VHTExtendedNSSBWCapable is not true, Indicates the maximum value of the TXVECTOR parameter MCS of a PPDU that can be transmitted at all channel widths supported by this STA for each number of spatial streams.
If transmitted by a STA in which dot11VHTExtendedNSSBWCapable is true, this field combined with the Extended NSS BW Support subfield and the Dynamic Extended NSS BW Support subfield of the Operating Mode field determine tThe maximum value of the TXVECTOR parameter MCS of a PPDU is further modified by the Extended NSS BW Support subfield, as described in 9.4.2.158.2 (VHT Capabilities Information field) and and the Dynamic Extended NSS BW Support field of the Operating Mode field in 9.4.1.53 (Operating Mode
field).

The same logic which applied to 7686 also applies here.

Proposed Changes: 1055.06 “Definition”

If transmitted by a STA in which dot11VHTExtendedNSSBWCapable is not true, iIndicates the maximum value of the RXVECTOR parameter MCS of a PPDU that can be received at all channel widths supported by this STA for each number of spatial streams.
If transmitted by a STA in which dot11VHTExtendedNSSBWCapable is true, this field combined with the Extended NSS BW Support subfield and the Dynamic Extended NSS BW Support subfield of the Operating Mode field determine tThe maximum value of the RXVECTOR parameter MCS of a PPDU is further modified by the Extended NSS BW Support subfield as described in 9.4.2.158.2 (VHTCapabilities Information field) and the Dynamic Extended NSS BW Support field of the Operating Mode field in 9.4.1.53 (Operating Mode field).

Proposed resolution:

Revised. Make changes in <this-doc> under CID 7685. These changes reword the cited text to indicate that the RXVECTOR MCS is subject to additional constraints when dot11VHTExtendedNSSBWCapable is true.

7743 / 1074.27 / 9.4.3 / "A subelement that is not defined as extensible will not be extended in future revisions or amendments of thisstandard." -- what if it's marked a Yes, could it become Subelements? Or vice-versa? / Add "A subelement that is defined as extensible might become subelement-extended in future revisions or amendments of thisstandard. A subelement that is defined as subelement-extensible will remain so in future revisions or amendments of thisstandard." / MAC / Frame Formats

Proposed resolution:

Rejected.

The statements as indicated are sufficient for STAs built to the current revision to know what to do with any future revision. In the case of Extensible=Yes, they delete any “surplus”. In the case of Extensible=Subelements, they parse it as subelements.

It is not necessary to embed what amounts to guidance to future contributors to the Standard in the standard itself on this topic, as this guidance does not affect the implementation of a compliant implementation to the current standard.

7777 / 1226.34 / 9.6.20.4 / "Each provided element is an element as specified in 8.4.2 (Elements), that the transmitter of this frame is providing to the destination of the frame." is vacuous and fails to specify their nature and order / Delete this para and row 6 in the table above / MAC / Frame Formats

Proposed Resolution:

Rejected. The cited text permits elements to be included with no constraints on the content or ordering of the provided elements. Thus is it up to the implementation to determine this content and ordering.

7778 / 1227.24 / 9.6.20.5 / "The provided elements are elements, as described in 8.4.2 (Elements), that the transmitter of this frame is providing to the destination of the frame." is vacuous and fails to specify their nature and order / Delete this para and row 6 in the table above / MAC / Frame Formats

Proposed Resolution:

Rejected. The cited location contains: “The provided elements are elements, as described in 9.4.2 (Elements), that the transmitter of this frame provides to the destination of the frame, either in addition to the requested elements, or in an unsolicited Information Response frame.”

This clarifies the purpose of this field, distinguishing it from the requested elements.

The cited text permits elements to be included with no constraints on the content or ordering of the provided elements. Thus is it up to the implementation to determine this content and ordering.

7774 / 1240.19 / 9.6.21.2 / "One or more elements are present in this frame" -- these are already covered above / Delete this row / MAC / Frame Formats

Proposed resolution:

Rejected.

The cited text allows elements that are not listed in orders 1-9 to be included. The description refers to 11.33, which lists the elements that can be present.

7776 / 1241.24 / 9.6.21.3 / "One or more elements can appear in this frame" -- these are already covered above / Delete this row / MAC / Frame Formats

Rejected.

The cited text allows elements that are not listed in orders 1-10 to be included. The description refers to 11.33, which lists the elements that can be present.

7755 / 1355.53 / 10.22.2.7 / "A frame exchange may be one of the following:" -- but a frame exchange, or at least a frame exchange sequence, is more than the things indicated (see Annex G) / Add ", in the context of multiple frame transmission in an EDCA TXOP" / MAC / MAC Operation

Proposed resolution:

Revised,

Replace cited text with:

“A frame exchange, in the context of multiple frame transmission in an EDCA TXOP, may be one of the following:”

7103 / 1883.25 / 11.43 / "B0-B1 (BW) in TVHT-SIG-A1"- the MAC has no knowledge of the contents of particular signal fields in the PHY (rightly so). / Reword so that this refers only to TXVECTOR/RXVECTOR parameters. / EDITOR / MAC Operation

Discussion:

Table 22-13 (2648.33) contains the mapping from TVHT_MODE to the BW field (Shown as PPDU type in this table). So showing the BW field contents is unnecessary.

Ignoring the irrelevant question of how the MAC tells the PHY the PPDU type (which I couldn’t answer after 15 minutes of research), we can safely delete that column.

Proposed resolution:

Revised. At 1883.24 deleted the column headed “B0-B1 (BW) in TVHT-SIG-A1”

Status: Defer on Peter E.

7235 / 2311.30 / 18.3.2.2.1 / This subclause duplicates the information in 16.2.3.5 / Change to just refer back to 16.2.3.5 / GEN / Editorials

Context: 2311.28

Proposed Resolution:

Revised.

Delete Table 18-4.

Replace the para at 2311.38 with:

“The SERVICE field is defined in 16.2.3.5.

An ERP STA shall set the Locked clocks bit to 1, when transmitting at a data

rate described in Clause 16 (High rate direct sequence spread spectrum (HR/DSSS) PHY specification).”

Delete the subclause 18.3.2.2.2 and its contents.

Delete the subclause heading 18.3.2.2.1, thus leaving the existing contents under 18.3.2.2.

7411 / 2504.51 / 21.2.5.2 / "PHY-TXSTART.request(TXVECTOR) primitive is issued" -- to what? There is no OFDM PHY / Use "as if" wording, as above / EDITOR / Editorials

Status: comment 7412 is related, which Sigurd had proposed a similar resolution to the above. However, Mark R requested this be pulled and suggested the following resolution:

Mark R proposes the following change for 7411 (and a similar change would be necessary in 7412):

The Clause 21 (Very High Throughput (VHT) PHY specification) TXVECTOR parameters in Table 21-1
(TXVECTOR and RXVECTOR parameters) are mapped to Clause 17 (Orthogonal frequency division
multiplexing (OFDM) PHY specification) TXVECTOR parameters in Table 17-1 (TXVECTOR
parameters) according to Table 21-3 (Mapping of the VHT PHY parameters for NON_HT operation) and
the Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification) PHY-
TXSTART.request(TXVECTOR) primitive is issued.
to:
where the Clause 21 (Very High Throughput (VHT) PHY specification) TXVECTOR parameters in Table 21-1
(TXVECTOR and RXVECTOR parameters) are mapped to Clause 17 (Orthogonal frequency division
multiplexing (OFDM) PHY specification) TXVECTOR parameters in Table 17-1 (TXVECTOR
parameters) according to Table 21-3 (Mapping of the VHT PHY parameters for NON_HT operation) and
the Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification) PHY-
TXSTART.request(TXVECTOR) primitive is issued.

Context:

wWhere tThe Clause 21 (Very High Throughput (VHT) PHY specification) TXVECTOR parameters in Table 21-1
(TXVECTOR and RXVECTOR parameters) are mapped to Clause 17 (Orthogonal frequency division
multiplexing (OFDM) PHY specification) TXVECTOR parameters in Table 17-1 (TXVECTOR
parameters) according to Table 21-3 (Mapping of the VHT PHY parameters for NON_HT operation) and
the Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification) PHYTXSTART.request(TXVECTOR) primitive is issued.

Proposed changes:

Revised. At 2504, replace “The” with “where the”.

At 2504.50 delete “and the Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification) PHYTXSTART.request(TXVECTOR) primitive is issued”

7543 / 3615.18 / R.5.3 / " an AP Advertisement location capability does not return an "incapable" response if the non-AP STA requests the "remote" location." makes no sense? / Change to something like "an AP avertising location capability does not return an "incapable" response if the non-AP STA requests the "remote" location." / MAC / Annex R

Context: 3614.57:

If location information is required in a particular regulatory domain, request location
information from the WLAN. If the STA cannot determine its own location by its own means,
then Location information should be obtained from the network prior to initiating the
emergency call request. There are two methods a non-AP STA can use to obtain location
services from the IEEE Std 802.11 network:
…
ii) If the non-AP STA requires location information in Civic or geospatial formats, then an
AP’s wireless network management capability canbe used. In this case, an AP advertises
its ability to provide its location in with Civic or geospatial format by setting the Civic
Location or Geospatial Location field in the Extended Capabilities element to 1. in the
Beacon frame. A non-AP STA requests its location using the procedures in 11.25.7
(Interworking procedures: emergency alert system (EAS) support). Unlike an AP
providing RM capability, an AP Advertisement location capability does not return an
“incapable” response if the non-APSTA requests the “remote” location.

Proposed Resolution: