|
Adrian Stephens
|
2051
|
199
|
Adrian Stephens
|
G
|
Y
|
1133.38
|
9.4.4.3
|
Desire considered dangerous. We have 136 instances of desire(d|s). But STAs don't have desire. Worse, when used in the passive voice (e.g. "the desired UP", "unless extra protection against
PCF collisions is desired.") the identity of the entity suffering these pangs of desire is discretely hidden.I claim that this word is harmful and should be eliminated. "unless extra protection against PCF collisions is desired" could become "unless a STA
determined that extra protection against PCF collisions is needed. How a STA makes this determination is implementation defined."
|
Review all uses of "desire" and replace with non-emotive language based on observables.e.g. "desired" BSSIS can become a target BSSID.
|
MAC
|
Needs submission
|
Propose: Agree in priniciple. Needs a submission.
|
Assigned
|
|
Adrian Stephens
|
2060
|
199
|
Adrian Stephens
|
G
|
N
|
3050.34
|
O.2
|
The changes indicated in the resolution of comment 234 on figure O-3 made no sense to me as editor.
|
Please review Figure O-3 versus the resolution of comment 234 and determine if any additional changes are necessary.
|
GEN
|
Discuss
|
See CID 2463
|
Assigned
|
|
Adrian Stephens
|
2094
|
199
|
Adrian Stephens
|
T
|
Y
|
1294.21
|
9.35.2.2
|
"may ignore DMG Beacon frames" -- what is the normative effect of "ignoring" something? Is this actually an exception to behaviour described elsewhere?
|
Add the exception to the material it is an exception to.
|
MAC
|
|
|
Assigned
|
|
Adrian Stephens
|
2157
|
199
|
Adrian Stephens
|
G
|
Y
|
1437.35
|
10.4.10
|
Generally there's a lot of unnecessary qualification introduced by .11ad. For example in " PCP shall send a DELTS frame to the non-PCP DMG STA", it is unnecessary to include DMG in "non-PCP
DMG STA" because the PCP cannot send a DELTS to a non-DMG STA. We went through a process in REVmb days of removing unnecessary "QoS" qualifications. Looks like we might need to do the same for DMG.
|
Review this subclause and remove any unnecessary qualification.
|
MAC
|
|
|
Assigned
|
|
Adrian Stephens
|
2177
|
199
|
Adrian Stephens
|
T
|
Y
|
2184.15
|
21.3.10
|
Either the changes made for Motion 34 (less than becomes less than or equal) are incorrect, in which case they should be unmade. Or they are correct, in which case matching changes need
to be made in the other PHY clauses, and on the equation line below.Changes at lines 15 and 22.
|
Either unmake changes or propagate to other PHYs.
|
GEN
|
Needs submission
|
|
Assigned
|
|
Adrian Stephens
|
2182
|
199
|
Adrian Stephens
|
T
|
Y
|
2219.58
|
21.9
|
"the PHY shall maintain (#1601)PHY-CCA.indication(BUSY) primitive for any signal 20 dB higher" -- Indications are discrete events, not continuous signals. "shall maintain" is incorrect.
|
Propagate changes for the same reason from the HT PHY.
|
GEN
|
Needs submission
|
|
Assigned
|
|
Adrian Stephens
|
2183
|
199
|
Adrian Stephens
|
G
|
Y
|
2383
|
B.4.24.1
|
Invalid or bogus references at:2386.10 (8.4.2.111.2), 2386.11 (11.3), 2386.15 (8.4.2.145),2386.23 (9.13a9.14),2387.31 (9.4.2.138), 2387.35 (8.4.2.140),2387.44 & 2387.57 (8.4.2.138),2392.55
(8.4.2.138), 2392.59 (8.4.2.140),2393.07 (8.4.2.138), 2393.11 (8.4.2.140)
|
|
GEN
|
Needs submission
|
GEN: 2014-02-21 16:00:18Z change assignment to Adrian
|
Assigned
|
|
Adrian Stephens
|
2185
|
199
|
Adrian Stephens
|
G
|
Y
|
|
|
There are ~30 "shall ignore" statements.The danger with these, is that they are used to create exceptions to rules, without recording the exception in the rule itself.Or they are clarifications
that no such requirement exists.For example: "If A then do B. If A and C, Ignore A."This should instead be "If A and not C, do B."
|
Review all "shall ignore" statements and replace them either:1. With an informative note " ... ignores ..."2. By adding an exception to a separate rule tha the "shall ignore" attempts
to "override".
|
GEN
|
Needs submission
|
|
Assigned
|
|
Adrian Stephens
|
2463
|
199
|
Mark Hamilton
|
T
|
Y
|
3050.27
|
O.2
|
The Editor was right to be unsure about the resolution to CID 234, there is an error in Figure O-3. The AID 0 arrow should not be there to the second row. Also the O-5 changes are not
complete.
|
Delete the second (lower) arrow for AID 0 in Figure O-3. On Figure O-5, add an indication of AID 0, with a split arrow to both the left cells (first and second row). Change the title
of Figure O-7 to "Partial Virtual Bitmap example #5" (including lower-case 'e').
|
GEN
|
Discuss
|
GEN: 2014-03-18 09:59:43Z - See CID 234 as well
Proposed Accept - See CID 2060
|
Assigned
|
|
Dorothy Stanley
|
2401
|
199
|
David Hunter
|
T
|
Y
|
3036.17
|
|
Recommended practices ("should" statements) do not belong in an informative clause (Annex N).
|
Do one of:-- Replace "Recommended practices: in the title of N.2 with "Current practices" and rewrite all of the "It is recommended" statements as statements of fact about current practices--
Delete N.2.-- List Annex N (on page 3038) as normative.
|
GEN
|
Discuss
|
GEN: 2014-03-12 initially started to review, more discussion needed.
|
Assigned
|
|
Dorothy Stanley
|
2411
|
199
|
Graham Smith
|
T
|
Y
|
1949.01
|
16
|
As noted in CID 32,"11b is Poison". Clause 16 devices have the capability of bringing 2.4GHz networks to their knees. 13/0416 (latest is r5 at time of writing comment) shows that there
is no technical reason to maintain Clause 16 devices. It is suggested that a note be added to this Clause to indicate that it is now 'out of favor' and that it is likely to be dropped in the (near) future.
|
Add text under heading "Devices supporting the DSSS system are no longer encouraged and likely to be deprecated from this Specification in subsequent revisions"
|
GEN
|
Needs submission
|
|
Assigned
|
|
Dorothy Stanley
|
2412
|
199
|
Graham Smith
|
T
|
Y
|
1974.01
|
17
|
As noted in CID 32,"11b is Poison". Clause 17 devices are coupled to Clause 16 DSSS and as such have the capability of bringing 2.4GHz networks to their knees. 13/0416 (latest is r5 at
time of writing comment) shows that there is no technical reason to maintain Clause 16 or 17 devices. It is suggested that a note be added to this Clause to indicate that it is now 'out of favor' and that it is likely to be dropped in the (near) future.
|
Add text under heading "Devices supporting the high rate extention to the DSSS system are no longer encouraged and likely to be deprecated from this Specification in subsequent revisions"
|
GEN
|
Needs submission
|
|
Assigned
|
|
Dorothy Stanley
|
2423
|
199
|
John Coffey
|
T
|
Y
|
2048.25
|
9.1.2
|
The standard requires 11n and 11g (i.e., HT and ERP) PHYs to support transmit and receive of all 11b modes. Given the enormous disparity in efficiency between 11b and the OFDM modes,
this no longer makes sense as a universal requirement for all products, and any such requirements should be removed, if not necessary to support coexistence. A straightforward way of accomplishing at least some of this is to remove the requirement that ERP
PHYs support the 5.5 and 11 Mbps CCK data rates. Since Clause 20 (HT) references Clause 19 (ERP), this would remove 5.5 and 11 Mbps as requirements for HT also. This would not affect the requirment to be able to detect the long or short preamble (1 Mbps and
2 Mbps) and to take appropriate action based on such a detection, thus preserving the current level of coexistence.
|
Delete 5.5 and 11 from list of mandatory data rates for ERP PHY. Also make corresponding changes throughout, including section 9.1.3 (P2048 LL30-37) (add 5.5 and 11 to list of exceptions);
section 19.3.5 (P2054 LL39-40) (delete 5.5 and 11 from list); and Annex B.4.9 (P2307 LL33-37) (remove 5.5 and 11; add new entry ERP1a for 5.5 and 11, optional)
|
GEN
|
Needs submission
|
|
Assigned
|
|
Dorothy Stanley
|
2424
|
199
|
John Coffey
|
T
|
N
|
2048.37
|
9.1.3
|
The standard requires 11n and 11g (i.e., HT and ERP) PHYs to support transmit and receive of the 11b Short Preamble. This is optional for 11b. This requirement no longer makes sense (if
it ever did), as there are legacy deployed devices that do not recognize the short preamble or defer for it, and it seems that most deployed devices do not transmit the short preamble.
|
Remove the sentence beginning "In addition, it is mandatory ...". Also make corresponding changes throughout, including section 19.3.2.1 (P2052 LL32-41) (change "three" to "two" and delete
short preamble from list; add extra line saying that an ERP STA may support the short preamble); section 19.3.2.3 (P2053 L16) (delete sentence begiining "For the ERP..."); section 19.3.5 (P2054 L40) (delete "or short"), and (P2054 L46) (delete "short preamble").
|
GEN
|
Needs submission
|
|
Assigned
|
|
Graham Smith
|
2413
|
199
|
Graham Smith
|
T
|
Y
|
2027.12
|
18.3.10.6
|
We know where -82dBm comes from (min sensitivity). Is it OK to assume the 'common' -72dBm was chosen simply on 10dB above this level (i.e. about 50% of the range - not really as on practice
-92dBm is minimum sensitivity)? Similarly the common -62dBm as 20dB above minimum (i.e. about 25% of the extreme range)? Is there any regulatory basis for this or, most likely, is it based on letting a Wi-Fi STA at the furthest range get in? This is based
upon maximum range concerns not so much a 'managed' range/cell. There is a real case to consider allowing higher CCA such that the overall traffic can be increased as explained in presentation 13/1012
|
Change CCA levels from mandatory. Consider allowing new CCA text which could be proposed by commenter. This also applies to Clauses 19.4.5 and 20.3.20.5.2
|
GEN
|
Needs submission
|
|
Assigned
|
|
Mark Hamilton
|
2005
|
199
|
Adrian Stephens
|
T
|
Y
|
29.44
|
3.2
|
The "See EAPOL-Key frame" is bogus, because the two terms are no longer synonyms.
|
Add a definition, or delete cited entry
|
MAC
|
Review
|
MAC: 2014-03-09 20:16:47Z: Revised. Change the definition of EAPOL-Start to be "A Data MPDU that carries all or part of an 802.1X EAPOL PDU of type EAPOL-Start."
|
Assigned
|
|
Mark Hamilton
|
2009
|
199
|
Adrian Stephens
|
G
|
Y
|
140.01
|
6.3.4.2.2
|
The JOIN.request primitive is of dubious use. In a non-FHSS (remember, we just got that to hop out of the standard), this has no effect on behavior. No frames are transmitted based on
this primitive. No state machines are affected.Why then does this primitive still exist?And if we want to keep the primitive, why does it need things like HT Operational Rate Set?
|
Remove the MLME-Join primitives and all references to them.Or failing that, delete all but the Selected BSS parameter.
|
MAC
|
Discuss
|
MAC: 2014-03-10 03:46:14Z: Propose: Reject.
MLME-JOIN serves an explicit purpose, as described in 10.1.4.5. In particular, the non-AP STA will synchronize its TSF to the AP (allowing it to follow Beacon timing from this point in time). This primitive is also used to set a number of operating parameters
which are otherwise not in any MLME primitive issued by a non-AP STA (for example, the rate set parameters, including HTOperationalMCSSet). In this way, the MLME-JOIN is parallel to the MLME-START in terms of initializing the MAC to specific (perhaps non-default)
operating parameters.
It is agreed that there is some redundancy between MLME-JOIN and later primitives (especially MLME-ASSOCIATE). A submission is needed to address this, specifically.
|
Assigned
|
|
Mark Hamilton
|
2054
|
199
|
Adrian Stephens
|
G
|
Y
|
1152.11
|
9.11
|
What is a "non-DMG network"? Surely better to related to transmission by a non-DMG STA, in which case why not insert "non-DMG" twice, as is done elsewhere?
|
Replace "in a non-DMG" network by inserting "non-DMG" betfore STA at the start of these two statements. Remove the introductory sentence and promote to body text.
|
MAC
|
Review
|
MAC: 2014-03-10 04:25:34Z - Revised. Accept proposed changes. Also, at 1116L18, delete "in a non-DMG network"; at 1158L7, replace "non-DMG network" with "non-DMG BSS"; at 1167L60, replace
"non-DMG network" with "non-DMG BSS"; at 1227L21, replace "non-DMG network" with "non-DMG BSS"; at 1227L25, replace "DMG network" with "DMG BSS".
|
Assigned
|
|
Mark Hamilton
|
2119
|
199
|
Adrian Stephens
|
T
|
N
|
97.39
|
4.9.3
|
"Since multiple STAs coordinated by the same MM-SME share the PHY, the STAs do not directly exchange frames with each other."I am not sure exactly what this is saying. Is it saying that
the STAs do not need to exchange frames, or are not capabile of exchaning frames?If it is saying they cannot, then we have changed the meaning of the MAC service to one that can neither transmit nor receive from certain MAC addresses. For example, a broadcast
does not reach all the MACs in the BSS (ignoring packet errors) because of this.
|
Add these constraints to the description of the MAC data service.
|
MAC
|
Review
|
MAC: 2014-03-09 20:45:11Z: Revised. Change, "STAs do not directly exchange frames with each other" to "STAs can not directly exchange frames with each other."
This addresses the ambiguity of the statement.
As for the MAC Service, nowhere does the MAC Service say or imply that all STAs can exchange frames directly with each other - consider hidden nodes, for example. Thus, no further change is needed.
|
Assigned
|
|
Mark Hamilton
|
2154
|
199
|
Adrian Stephens
|
G
|
Y
|
1432.23
|
10.4.4.4
|
"All MSDUs corresponding to a TID that was successfully negotiated through the ADDTS exchange with a U-PID element with the No-LLC field equal to 1(M34) shall have their LLC header stripped
before transmission and the agreed LLC header added before delivery at the peer MAC-SAP. (11ad)"Passive voice considered dangerous. The following statement "shall have ... stripped" hides who does this. Also this is not an MLME activity, but a MAC data-plane
activity, and may be above the MAC data SAP.
|
Determine where the stripping takes place. If it is in the MAC data plane, move this statement into clause 9. If it is above the MAC data plane, this is out of scope, and move it to an
informative annex.Reword so that it cites the entity responsible for this action.
|
MAC
|
Review
|
MAC: 2014-03-18 09:25:28Z: Revised. Change to, "Before transmission, the MAC shall strip the LLC header from all MSDUs corresponding to a TID that was successfully negotiated through
the ADDTS exchange with a U-PID element with the No-LLC field equal to 1, and the negotiated header shall by added by the peer MAC before delivery at the peer MAC-SAP."
|
Assigned
|
|
Mark Hamilton
|
2155
|
199
|
Adrian Stephens
|
T
|
Y
|
1434.4
|
10.4.7
|
The changes from CID 1412 removed the ADDTS failure timeout. The changes to the figures 10-16 should be more radical than described in that comment resolution, because now a .confirm
is not provided in the case of timeout. Errors are handled above the MLME by the SME, which might choose to send an MLME-DELTS.request to cover case 2.
|
Remove the timeout from the two cases in Figure 10-16. Consider adding mandatory SME behavior on timout to send a DELTS.request in the case of timeout.Remove the text: "shall send a DELTS
to the HC specifying the TSID and direction of the failed request"
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
2168
|
199
|
Adrian Stephens
|
G
|
Y
|
1623.4
|
10.33.2.2
|
Embedded "magic numbers"
|
Replace with name of status code throughout table.
|
MAC
|
Needs submission
|
MAC: 2014-01-17 05:44:40Z: Agree completely, and the text just before, and a few pages after the table has the same problem.
However, the root cause of this problem is that table 8-42 doesn't have a name for very many of the values, so there is no agreed name to reference in other locations like the cited location.
See CID 91 which was intended to address the root cause. Then, the cited location (and nearby text) could be modified to align. But, CID 91 died of loneliness.
|
Assigned
|
|
Mark Hamilton
|
2360
|
199
|
David Hunter
|
E
|
Y
|
1470.19
|
10.11.4
|
Confused writing makes the requirements unclear. What exactly does "shall not be set to 0 except for Beacon request with Measurement Mode set to Beacon Table Mode, Statistics request
and request for triggered autonomous measurements." mean? Also: "Beacon Table Mode" does not appear to be the name of a frame, field, element, etc, so should be in lower case. Is it clear what type of frame constitutes the last type of request? Where is that
specified?
|
Delete the comma after "frames" and replace the quoted sentence fragment with "shall not be set to 0 except when the request frame is a Beacon request in which the Measurement Mode field
value is beacon table mode, or is a Statistics request frame, or is a request for triggered autonomous measurements." And specify exactly what frames make up the "request for triggered autonomous measurements". Also specify explictly somewhere (MIB?) the value
of "beacon table mode".
|
MAC
|
Discuss
|
MAC: 2014-01-19 16:50:09Z - Is the terminology (for example), "Statistics request frame" what we want to use for a Measurement Request frame that has a Measurement Report element which
has the Measurement Type field set to STA statistics report? The full description is way too wordy, and we need shorthand phrase. What is the right/best shorthand?
A nit: there is also a Directional statistics report, so we cannot shorthand to just "statistics", we need to say "STA statistics"
EDITOR: 2013-10-25 13:49:11Z
The proposed resolution does not address 'And specify exactly what frames make up the "request for triggered autonomous measurements"', which requires technical interpretation.
Transferring to MAC to continue the resolution. The resolution as of this date will be present in D2.1, and will be adjusted to track any subsequent changes in MAC.
|
Assigned
|
|
Mark Hamilton
|
2410
|
199
|
Graham Smith
|
T
|
Y
|
2745.02
|
|
dot11HRCCAModeImplemented only appears in Annex C.3 I can find no reference to it outside of Annex C.3. Suggest it is deleted.
|
Delete dot11HRCCAModeImplemented at P2745L2, P2753L57, P2754L8-27, P2819L37
|
GEN
|
Needs submission
|
GEN: assigned to Mark HAMILTON - Dec 20, 2013
|
Assigned
|
|
Mark Hamilton
|
2434
|
199
|
Mark Hamilton
|
T
|
Y
|
116.01
|
5.2.1
|
Figure 5-1 is confusing. It looks a lot like 802.1Q's bridge diagram, but this is not at all the same thing. It also has several unlabeled blocks which are confusing. And, it implies
that 802.1X port control is above LLC which is incorrect.
|
Replace Figure 5-1 with that contained in a submission from the ARC SC.
|
GEN
|
Needs submission
|
|
Assigned
|
|
Mark Hamilton
|
2454
|
199
|
Mark Hamilton
|
T
|
Y
|
1093.19
|
9.2.2
|
Figure 9-1 still has FH, IR, etc.
|
Delete "FHSS, IR" from this figure
|
MAC
|
Review
|
MAC: 2014-03-18 09:00:02Z: Changes already made by the Editor.
|
Assigned
|
|
Mark Hamilton
|
2455
|
199
|
Mark Hamilton
|
T
|
Y
|
1093.02
|
9.2.2
|
Figure 9-1 line to DCF is confusing
|
Draw the figure so that label connectors don't have to pass "behind" boxes (making it look like they are connecting to that box). Push the label off to one side so that it's connector
can be drawn without disappearing behind boxes. (If it has to disappear behind other labels, that's not ideal, but better.) Do this for the DCF label and the SP Access label.
|
MAC
|
Review
|
MAC: 2014-03-18 07:59:37Z: Revised. Redraw with the two referenced labels moved to the side and down, as shown in 14-0422r0.
|
Assigned
|
|
Mark Hamilton
|
2458
|
199
|
Mark Hamilton
|
T
|
Y
|
1160.6
|
9.20.2.3
|
EDCAF operation needs help to improve understanding - it has not evolved well. For example, 9.19.2.3 has become a convoluted machine built from 4 separate bullet lists. 9.19.2.3 and 9.19.2.5
both discuss backoff counter decrements, and when they occur. 9.2 shows EDCA as "on top of" DCF, but EDCA TXOPs violate 9.3.4.3 (6th paragraph). Etc.
|
This needs off-line work, and a thought-out proposal.
|
MAC
|
Needs submission
|
|
Assigned
|
|
Mark Hamilton
|
2459
|
199
|
Mark Hamilton
|
T
|
Y
|
217.32
|
6.3.26.6.2
|
Get rid of all TIMEOUT and UNSPECIFIED_FAILURE ReasonCode values, unless there is discussion of them explicit in the protocol/behavior (and then give them a descriptive name)
|
Get rid of all TIMEOUT and UNSPECIFIED_FAILURE ReasonCode values, unless there is discussion of them explicit in the protocol/behavior (and then give them a descriptive name)
|
GEN
|
Needs submission
|
|
Assigned
|
|
Mark Hamilton
|
2460
|
199
|
Mark Hamilton
|
T
|
Y
|
588.01
|
8.4.1.9
|
All StatusCodes and ResultCodes should have a name
|
It's just easier to talk about these, if they have a name.
|
MAC
|
Needs submission
|
|
Assigned
|
|
Mark Hamilton
|
2462
|
199
|
Mark Hamilton
|
T
|
Y
|
1417.42
|
10.3.5.4
|
Reassociation to the same AP behaviour is not clearly defined (e.g. effect on TSes, whether failure leaves you unassociated, whether you need to re-do 4WH, meaning of PM bit in Reassociation
Request, etc.)
|
Clarify that reassociation to the same AP transitions the non-AP STA to not be in power save mode. No other behaviors are affected.
|
MAC
|
Needs submission
|
MAC: 2013-11-13 22:37:13Z: Yes, you shall do the 4WH again (or FT) - well, you will lose your PTK.
Did the group that shall not be named agree with the above?
Check on TSes, too. And, testing of the above.
It might be wishful thinking to think anything will be retained. (Could put in text warning of this.)
|
Assigned
|
|
Mark Hamilton
|
2464
|
199
|
Mark Hamilton
|
T
|
Y
|
510.51
|
8.2.4.1.7
|
The rules in 8.2.4.1.7 are not consistent with 10.2.2.2.The concepts "MMDU is bufferable" and "PM bit is reserved" need to be separated. It makes no sense to say that an Action MMDU sent
by a non-AP STA is bufferable, for example, just because you want to be able to say that the PM is valid in the MPDUs used to send it.The exception for the PM bit in Probe Responses sent in response to unicast Probe Requests in an IBSS makes no senseIt's not
clear enough which Control MPDUs have non-reserved PM bits and when. Note for example that 8.2.4.1.7 implies the PM bit in ACKs sent by a non-AP STA are not reserved.
|
Consider documents 11-12/1199 and 11-13/0131
|
MAC
|
Needs submission
|
|
Assigned
|
|
Mark Rison
|
2425
|
199
|
Jon Rosdahl
|
G
|
Y
|
2233.01
|
|
CID 269: Scrub PICS: was was assigned to Mark RISON -- who created 11-12/1345r0, the submission was overreaching, and corrected more than was requested/thought by the comments.
|
Document 11-12/1345r0 contains many changes to the PICS that would be a positive change. A new Document will be prepared to identify those changes and submitted to the REVmc Task Group
|
GEN
|
Needs submission
|
|
Assigned
|
|
Matthew Fischer
|
2471
|
199
|
Matthew Fischer
|
T
|
Y
|
1155.55
|
9.19
|
Several elements and frames use the operating class. Additions were made to the operating class for 11n and 11ac. These additions were for wider BW modes - older STA do not understand
those operating classes, but the STA operating in the new operating classes generally include backwards compatible operating modes.e.g. 11ac includes 80 mhz BW operation and there is an operating class to support thislegacy 11a STA do not understand the new
operating class, but they can probably still associate as 20 mhz only STA, and therefore, would benefit by knowing that the 20 mhz operating class is supported by the target BSS/APTherefore, whenever operating class is transmitted, it should be transmitted
with the highest possible mutual understood operating class between the sender and the receiver, limited by the highest supported operating class of the third party being described
|
|
MAC
|
Needs submission
|
|
Assigned
|
|
Matthew Fischer
|
2473
|
199
|
Matthew Fischer
|
T
|
Y
|
629.62
|
8.4.2.3
|
Add a BSS membership selector for "private network" with the membership requirement to join the private network found in a specific location, e.g. include a new IE which contains an OUI
field and a type field which together are a reference to a VSIE that matches that OUI value and with the type octet matching the octet that immediately follows the OUI value in the VSIE. The VSIE provides further details of what is required for membership,
expressed in a vendor-specific manner.
|
As suggested.
|
MAC
|
Needs submission
|
|
Assigned
|
|
Matthew Fischer
|
2479
|
199
|
Matthew Fischer
|
T
|
Y
|
539.08
|
8.3.1.9.1
|
The highest indicated modulation and stream combinations for some PHYs result in phy rates that will reduce throughput efficiency to exceedingly low levels if the maximum block ack window
size is not allowed to increase beyond the existing 64.
|
Increase the maximum allowed MPDUs in the Block Ack frame to 256 by creating a new form of Block Ack that supports a longer BA window and a longer BA bitmap
|
MAC
|
Needs submission
|
|
Assigned
|
|
Matthew Fischer
|
2481
|
199
|
Matthew Fischer
|
T
|
Y
|
1142.14
|
9.7.6.5
|
ACK (and other control response frames) are supposed to be sent at rates as specified in this subclause. Generally speaking, this subclause prescribes ACK transmission at a Basic Rate,
which is, for eliciting frames that are transmitted at higher rate or MCS values, typically a rate that is lower than the rate or MCS of the eliciting frame by at least two increments. When the eliciting frame is at one of the lower rates/MCS, then the ACK
will often be at the same rate/MCS. Normally, this is ok - reliability of the ACK transmission is good or better than the eliciting frame because the eliciting frame usually has significantly more bits than the ACK. But if the eliciting STA has a higher TX
power, then the rate for the ACK can be too high and is very likely to fail. It would be nice if the eliciting STA can signal to the responder that a lower rate/MCS will be needed. This ensures a receiveable ACK and it allows the eliciting STA to correctly
compute the ACK duration for DUR field use.
|
Allow a control response frame to be sent at a rate/MCS lower than otherwise allowed when there is a power difference or for other reasons. Create a mechanism that allows the eliciting
STA to indicate the preferred response rate/MCS. E.g. signal in the eliciting frame, a value of step down in rate/MCS from the normally computed value for the response frame.
|
MAC
|
Needs submission
|
|
Assigned
|