[STDS-802-11] Deleting the HTOperationalMCSSet

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

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.