Re: [STDS-802-11] Deleting the HTOperationalMCSSet

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hello Matt,

Please see below.

Best Regards,

Adrian P STEPHENS

Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile, UK)

Tel: +1 (408) 2397485 (mobile, USA)

----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

From: *** IEEE stds-802-11 List *** [mailto:STDS-802-11@xxxxxxxx] On Behalf Of Matthew Fischer
Sent: 12 February 2014 22:30
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] Deleting the HTOperationalMCSSet

--- This message came from the IEEE 802.11 Working Group Reflector ---

It sounds like you are trying to include at least the HTOperationalMCSSet within the OperationalRateSet.

Adrian: No, I’m not. The OperationalRateSet has to be maintained, because that’s the only thing

that defines “supported rates” for pre-11n devices. I started out trying to remove redundant stuff.

I decided the HT Basic MCS Set was definitely redundant.

I ended up deciding tha the HT Operational MCS set was not redundant, but was useless. Ditto the

VHT Operational MCS set. If the HT feature was useful, it would have been duplicated in .11ad

and .11ac. It was not duplicated in .11ad and an even more useless shadow was implemented in

.11ac.

But I am not certain…

The MIB definition of the dot11OperationalRateSet specifically calls out “non-HT” – so if the dot11OperationalRateSet is to include HT rates, then don’t we need to eliminate that part too? See yellow highlight in the MIB definition:

The MIB variable is needed for Rates.

The best analogue of this MIB variable is the dot11SupportedMCSTxTable, which I am not proposing to remove.

And once we include every rate possible in dot11OperationalRateSet, aren’t there more than 127 values, so the variable needs to be extended?

And what about VHT rates?

dot11OperationalRateSet is specific to rates, not MCSs. I am not proposing to change its semantics.

I.e. the current MIB variable upper limit is 63.5 Mbps.

It needs to be redefined to support the higher rates of HT and VHT if you are going to eliminate the other rate sets (MCS sets).

And with your current suggested changes, you end up with a statement that says:

No STA is ever allowed to transmit at a rate higher than 63.5 Mbps for data and management frames.

(i.e. 1219.30 – which I find at 1139.40 in D2.0)

I’ll add a NOTE to clarify, but elsewhere, when we say “a rate” in 9.7, we are excluding modulations specified by an MCS.

I think that the reason why there is a separate MIB is because one is rates as Mbps and the other is MCS values, some of which have the same value if expressed as Mbps rounded to the nearest 0.5 Mbps.

This sounds like something that came up before….

It did. Pity that .11n, .11ad and .11ac all interpret it differently :0).

Matthew Fischer

From: *** IEEE stds-802-11 List *** [mailto:STDS-802-11@xxxxxxxx] On Behalf Of Stephens, Adrian P
Sent: Wednesday, February 12, 2014 8:59 AM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] Deleting the HTOperationalMCSSet

--- This message came from the IEEE 802.11 Working Group Reflector ---

Dear 802.11 members,

Apologies for the wide audience, but I’m trying to get the attention of a wide range of MAC folks who might not normally pay attention to REVmc.

Please reply to me directly to reduce spam. I’ll start a “local” email thread amongst any respondents.

I’m resolving a comment about duplication of functionality in the START.request primitive. Here is my proposed comment resolution:

2010

180.10

6.3.11.2.2

There is redundancy among some of the parameters of the START.request. Specifically the HT Operation parameters contains the HT BSS Basic rate, which is also a parameter.

Review the parameter list and remove any parameters that are embedded in some other parameter.

GEN

Discussion:

Redundancy exists around the BSSBasicMCSSet, which is present in the HT Operation element.

Redundancy possibly exists around the HTOperationalMCSSet, which duplicates information (supported MCSs) present in the HT Capabilities element. In this case the picture is more complex, because we have differing models emerging.

1. The OperationalRateSet parameter represents both a restriction on the devices transmit behaviour and the only thing known by other STAs about its receive capabilities. The value of this Set is exposed by a read-only MIB variable.

2. The HTOperationalMCSSet represents a restriction on a device’s transmit behaviour, independent of its capabilities. The value of this parameter is related to (presumably set by) a related read-write MIB variable. But the following are difficult:

a. “The STA’(#1485)s HTOperationalMCSSet shall include all of the MCSs in the BSSBasicMCSSet.” is a requirement on the external entity programming this MIB variable.

b.D2.0 182.16 “The STA shall be able to receive at each of the data rates listed in the set.” indicates that the .11n authors thought this was a receive capability, which it is not.

c. The BSS Description includes the HTOperationalMCSSet, but this set is not transmitted in a Beacon frame, so there is no way this can be known.

3. .11ad doesn’t have this parameter. It has mandatory MCSs and it has supported MCSs.

4. VHT has yet another model. Its OperationalVHTMCS_NSSSet provides a transmitter restriction, but is present only in the JOIN.request. There is no related MIB variable.

I propose to rationalize this by removing the .11n and .11ac Operational MCS sets and related normative specification throughout the standard.

Changes: (Related to D2.4, so that .11ac changes are included)

Delete HTOperationalMCSSet table row at 140.25 (BSS Description), 147.12 (JOIN), 191.19 (START)

Delete HTOperationalMCSSet parameter at 146.30 (JOIN.request), 189.11 (START.request)

Delete OperationalVHTMCS_NSSSet parameter at 146.39 (JOIN)

Delete OperationalVHTMCS_NSSSet table row at 147.51.

Change 1219.30:

A STA shall not transmit(#2142)a frame at a data rate higher than the greatest rate in the

OperationalRateSet~~, or using an MCS that is not in(11ac)the HTOperationalMCSset, or using a~~

~~<VHT-MCS, NSS> tuple that is not in the OperationalVHTMCS_NSSSet,(11ac)~~which is a~~are~~

parameters of the MLME-JOIN.request primitive.

Change 1614.56:

~~An HT STA that is creating or joining a BSS shall be able to receive at each of the MCS values listed in the STA’(#1485)s HTOperationalMCSSet.~~

~~The STA’(#1485)s HTOperationalMCSSet shall include all of the MCSs in the BSSBasicMCSSet.~~

Change 2700.07: (dot11OperationalRateSet)

DESCRIPTION

"This is a status variable.

It is written by the SME when joining or establishing a BSS.

This attribute specifies the set of non-HT data rates at which the station

may transmit data~~. The attribute that specifies the set of HT data rates~~

~~is dot11HTOperationalMCSSet.~~ Each octet contains a value representing a

rate. Each rate is within the range from 2 to 127, corresponding to data

rates in increments of 500 kbit/s from 1 Mb/s to 63.5 Mb/s, and is supported (as indicated in the supported rates table) for receiving data.

This value is reported in transmitted Beacon, Probe Request, Probe

Response, Association Request, Association Response, Reassociation

Request, and Reassociation Response frames, and is used to determine

whether a BSS with which the station desires to synchronize is suitable.

It is also used when starting a BSS, as specified in 6.3.4 (Synchronization)."

Change 2766.48:

dot11HTOperationalMCSSet OBJECT-TYPE

SYNTAX OCTET STRING (SIZE(1..127))

MAX-ACCESS read-write

STATUS deprecated~~current~~

DESCRIPTION

" Deprecated as no longer used by 802.11-<year>

This is a control variable.

It is written by an external management entity.

Changes take effect for the next MLME-START.request primitive or MLMEJOIN.request primitive.

Create a new group dot11HTMACAdditions2 that is a copy of dot11HTMACAdditions, less the dot11HTOperationalMCSSet. Deprecate dot11HTMACAdditions. Change dot11HTMACAdditions to dot11HTMACAdditions2 in dot11Compliances.

Best Regards,

Adrian P STEPHENS

Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile, UK)

Tel: +1 (408) 2397485 (mobile, USA)

----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

_______________________________________________________________________________

If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.

If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________

_______________________________________________________________________________

If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.

If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________

If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.