|
CID
|
Page
|
Line
|
Clause
|
Assignee
|
Submission
|
Comment
|
Proposed Change
|
Ad-hoc Notes
|
|
3471
|
1717.53
|
53
|
10.24.6.3
|
Brian Hart
|
|
There should be a mechanism to allow the initiating STA to known which parameter the responding STA is incapable of honouring
|
Use the Value field to indicate this (e.g. it could give the index of (one of) the field(s) which the rSTA is incapable of
|
|
|
3232
|
1009.01
|
1
|
8.4.2.136
|
Carlos Cordeiro
|
11-14/1594r0
|
It is not stated anywhere which frame(s) are used to carry the Awake Window element.
|
Add AwakeWindow to DMG Beacon and Announce frame body (Table 8-49 and Table 8-401), or state in 8.4.2.136 that the element can be carried in DMG Beacon and Announce frames, or other solution.
|
MAC: 2015-01-13 19:18:44Z - REVISED (MAC: 2015-01-13 19:05:19Z): Make the changes as noted in 11-14/1594r3 as noted for CID 3232. [Consider on Wed]
MAC: 2014-12-22 19:01:51Z - Discussed Dec 12, still some open discussion (captured in 11-14/1568), Carlos will bring back.
MAC: 2014-11-21 15:24:42Z: From telecon: Simple addition as proposed is not agreed; need to add to tables. Ordering of fields debated - will be considered separately (needs a new comment).
|
|
3499
|
1211.28
|
28
|
8.6.22.2
|
Carlos Cordeiro
|
11-14/1594r0
|
"Multiple elements can appear in this frame." Like what? Anything? This is underconstrained. List what can, and makes sense, to put here; or something
|
Clarify what elements are sensible or expected in this frame.
|
MAC: 2014-12-22 19:01:51Z - Discussed Dec 12, still some open discussion (captured in 11-14/1568), Carlos will bring back.
|
|
3460
|
1551.44
|
44
|
10.2.2.16.4
|
Emily Qi
|
|
No behaviour is indicated for "Alternate Preferred, due to existing stream with different delivery interval", "Alternate Preferred, due to policy limits on AP" and "Alternate Preferred, due to AP changed the delivery interval" (and maybe
others?)
|
Add normative behaviour for all statuses
|
|
|
3209
|
1733.52
|
52
|
10.24.14
|
Gabor Bajko
|
|
The Proxy ARP functionality does not address how to handle the ARP Announcement packets used for Address Conflict Detection and Address Defense. It should be described, to avoid inconsistent behaviour among different Proxy ARP implementation.
|
Submission will be provided.
|
MAC: 2014-09-18 11:34:18Z: Considered 11-14/1173r1. Jouni asked for further time to review. Mark H noted that the uplink announcements need to be explicitly 'blocked' at the AP (so that it doesn't duplicate if it generates one), and if
the AP does generate one it needs to go to the DS (and thereby 'elsewhere'), and not just to this BSS. Same thing on the IPv6 case, of course.
|
|
3523
|
554.54
|
54
|
8.2.4.1.7
|
Mark Hamilton
|
|
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 sense
It'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
|
|
|
3521
|
237.15
|
15
|
6.3.26.6.2
|
Mark Hamilton
|
11-14/1358r1
|
Get rid of all TIMEOUT ReasonCode values, unless there is explicit discussion of it in the protocol/behavior (and then give it a more descriptive name)
|
Get rid of all TIMEOUT ReasonCode values, unless there is explicit discussion of it in the protocol/behavior (and then give it a more descriptive name). I.e., change TIMEOUT in 6.3.26.6.2 (and 6.3.26.7.2, 6.3.27.6.2, 6.3.27.7.2, 6.3.29.6.2
and 6.3.29.7.2) ReasonCode to INACTIVITY_TIMEOUT; delete TIMEOUT from 6.3.93.10.2 and 6.3.93.11.2 (unless Relay links have a timeout semantics specified somewhere else); etc.
|
|
|
3459
|
1551.21
|
21
|
10.2.2.16.3
|
Mark Hamilton
|
|
There is no single "Alternate Preferred" status
|
Refer to the two specific statuses from table 8-203
|
|
|
3211
|
2361.16
|
16
|
20.4.4
|
Mark Rison
|
11-14/1104
|
aMPDUMaxLength is not defined in Table 20-25 (nor wasn't it defined in the 802.11n amendment). So what is the maximum length of an un-aggregated MPDU for the HT PHY? In Clause 16, 17, 18, and 19 this parameter is defined in the PHY characteristics
table. For 802.11a and 802.11g the value is 4096 octets. However, the dot11FragmentationThreshold MIB variable limits the longest transmission to be 2346, originally for both PHYs, under the rules of Clause 9, but this was later changed to be 3000 octets
in 802.11REVmb, and changed again in 802.11n to 8000 octets. With this last increase to dot11FragmentationThreshold, aMPDUMaxLength = 4096 octets became the effective limit for these two PHYs.
Now, in 802.11n, aMPUDMaxLength was not defined in the HT PHY parameters, although it is still required as one of the parameters in the initialization of the PHY primitive. aPSDUMaxLength = 65536, and the aPPDUMaxTime = 10ms were added, and the configurable
dot11MaxAMSDUlength MIB variable = either 7935 or 3839 (default) was added. These 3 parameters, together, do limit the PHY transmission in both the aggregated and unaggregated cases, but then the default value for dot11FragmentationThreshold, which becomes
the limit of an unaggregate packet, is ill-defined because aMPDUMaxLength is undefined for the Clause 20 HT PHY. All that is really known is that 8000 octets is the upper limit for dot11Fragmentation Threshold. (See the last sentence of the description
of dot11FragmentationThreshold on page 3120, line 57, which gives the equation for calculating dot11FragmentationThreshold as a function of aMPDUMaxLength.)
|
Define aMPDUMaxLength for the HT PHY. In this way, the length of the maximum unaggregated MPDU (and the default maximum fragment as defined by the value of dot11FragmentationThreshold in the MIB) will be well-defined, as well as the parameter
to the PHY initialization.
(Sorry for not finding this in REVmb or earlier ballots of REVmc.)
|
Some of the history is out-of-date. Nonetheless, the problem statement is accurate. Clauses 21, 22 and 23 probably have the same problem.
Need a submission suggesting what the aMPDUMaxLength should be for HT, DMG, VHT and TVHT, and providing rationale for the selection(s).
|
|
3462
|
|
|
|
Mark Rison
|
|
"Alternate Preferred" -- actually it's not a mere preference, it's an override
|
Change to "Overridden" throughout (10 instances in 8.4.2.76, 10.2.2.16.3, 10.2.2.16.4 and 10.24.8)
|
EDITOR: 2014-11-19 14:39:21Z -
This is turning into a technical debate. Transferring to MAC.
MGR: 2014-09-15 08:27:46Z - Then I'm confused by 1551.20: "If the AP selects an alternate delivery interval or alternate maximum delivery interval from the value
specified in the FMS Request, the FMS Status subelement shall be set to Alternate Preferred, and the FMS
subelement shall indicate the AP selected value(s)." It sounds like the AP has made the decision, not that it wants the STA to ask for something else.
|
|
3479
|
1823.09
|
9
|
10.40.4
|
Mark Rison
|
11-14/1104r4
|
For non-VHT STAs to be able to fully benefit from the new power/regulatory/channel switching stuff, it is necessary for them e.g. to be able to receive a unicast (Extended) Channel Switch Announcement MMPDU with e.g. a VHT Transmit Power
Envelope element
|
Add an Extended Capability bit to allow a non-VHT STA to indicate support for the VHT power/regulatory/channel switching stuff, and ensure the text requires VHT STAs to use the VHT power/regulatory/channel switching stuff with non-VHT devices
which have indicated this capability
|
|
|
3392
|
1272.11
|
11
|
9.6
|
Mark Rison
|
11-14/1413r0
|
"A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs. [...]
The destination STA shall maintain a Receive Timer for each MSDU or MMPDU being received, for a minimum of three MSDUs or MMPDUs." -- does this always apply (e.g. DMG STAs -- see end of 9.5 and 9.22.2.1; also what about the risk of MSDU/MMPDU reordering caused
by concurrent reception causing replay detection to discard MSDUs/MMPDUs)?
|
If it doesn't apply to all STAs, add suitable caveats
|
MAC: 2014-11-21 15:36:56Z - From telecon: Agree with the Reject proposal, as we are quite sure there is text somewhere else that does require this for all STAs. Need to recall that discussion (from the F2F in San Antonio) and find the
cite.
Will reconsider on the next telecon, and confirm that we've covered all the cases, and determined whether there are any special cases or not (after refreshing the memory of the F2F discussion, as well).
Assigned to Mark R, for now.
|
|
3301
|
587.50
|
50
|
8.3.1.1
|
Matthew Fischer
|
|
Implementations can benefit through the addition of another dynamic PS mechanism which is receiver bandwidth based. Add a BW-based dynamice PS mechanism.
|
Change the definition of the FC bits in the RTS frame to allow the More Frag, More Data, Protected Frame and Order bits to be used collectively to form the "TXOP Width" subfield which signals the width of the upcoming MSDU-bearing PPDUs
that follow the RTS. Each of the 4 bits indicates which portion of the BSS operating width is being used for the MSDU-bearing PPDUs such that one bit indicates use of the primary 20 MHz channel, another indicates use of the primary 40 MHz channel, the third
the secondary 40 MHz channel and the 4th bit indicates use of the secondary 80 MHz channel.
|
|
|
3299
|
711.60
|
60
|
8.4.2.3
|
Matthew Fischer
|
|
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. (continuation
of rejected LB199 CID 2473 - rejected due to insufficient information)
|
Add a row to Table 8-86 "BSS membership value encoding", the row to contain: value "125", feature "vendor specific", interpretation: "Support of vendor specific features is required in order to join the BSS that was the source of the Supported
Rates element or Extended
Supported Rates element containing this value. The vendor specific features are identified by the vendor specific OUI and type values listed in the Vendor Specific BSS Membership Selector Information Element" - add a new element "Vendor Specific BSS Membership
Selector IE" with a body that contains a variable length list of N "vendor specific BSS membership selector reference" fields, with the description for "vendor specific BSS membership selector reference field" as: Each vendor specific BSS membership selector
reference field has a three octet OUI value and a one octet type value, together each OUI/type pair describes a vendor specific element that matches the given OUI/type pair and which contains information that describes, in a vendor specific manner, BSS membership
conditions.
|
|
|
3298
|
1032.26
|
26
|
8.4.2.157.3
|
Matthew Fischer
|
11-14/793r3
|
There is no text in this subclause to define the fields Rx Highest Supported Long GI Data Rate or Tx Highest Supported Long GI Data Rate.
|
Add a sentence or two indicating that the Rx Highest Supported Long GI Data Rate field and Tx Highest Supported Long GI Data Rate are defined in Table 8-251.
|
See also 3297
|
|
3231
|
1349.43
|
43
|
9.24.4
|
Payam Torob Jahromi
|
|
If no MSDUs or A-MSDUs are passed up to the next MAC process after the receipt of the BlockAckReq frame and the starting sequence number of the BlockAckReq frame is newer than the NextExpectedSequenceNumber for that block ack agreement,
then the NextExpectedSequenceNumber for that block ack agreement is set to the sequence number of the BlockAckReq frame.
|
The statement is of the form "if (A and B) then C"; Break the if and define behavior for all combinations of A and B, including any missing ele statements (pseudo code in 9.24.7.3 seems to have defined a behavior).
|
|
|
3035
|
1829.56
|
56
|
10.43
|
Ron Porat
|
|
"A TVHT AP shall set the Channel Width subfield in the TVHT Operation Information field to indicate the BSS operating channel width and transmitted PPDU type depending on value of B0-B1 in TVHT-SIG-A1 field from those shown in Table 10-26
(TVHT BSS operating channel width" -- The MAC should not know about SIGNAL fields, only VECTOR parameters.
|
Replace: "of B0-B1 in TVHT-SIG-A1 field" with a reference to a TXVECTOR parameter.
|
|
|
3300
|
1029.23
|
23
|
8.4.2.157.2
|
Vinko Erceg
|
|
The universally complete set of architectures of VHT receivers does not imply identical spatial stream support for SU and MU cases. I.e. the ability to differentiate spatial stream support values for MU vs SU is missing. This comment also
applies to TVHT.
|
Change bits 30-31 of the VHT Capabilities Info field from reserved to "MU NSS Reduction" with a definition of the "The value of MU NSS Reduction field is an unsigned integer representing the reduction in the maximum number of spatial streams
that is supported by the STA when receiving or transmitting an MU PPDU as compared to the maximum number of spatial streams that are supported by the STA when receiving or transmitting an SU PPDU. The maximum number of spatial streams that are supported by
the STA when receiving or transmitting an SU PPDU is equal to the smaller of the maximum number of spatial streams supported by the STA when receiving an SU PPDU and the maximum number of spatial streams supported by the STA when transmitting an SU PPDU. The
maximum number of spatial streams supported by the STA when receiving an SU PPDU is the highest number of spatial streams for which the RX VHT-MCS map subfield does not contain the value of 3. The maximum number of spatial streams supported by the STA when
transmitting an SU PPDU is the highest number of spatial streams for which the TX VHT-MCS map subfield does not contain the value of 3. " As an alternative, even though it seems odd, one could place these new bits in some of the reserved bit locations of the
HT Cap IE in the Extended capabilities subfield where there are lots of bits available. All VHT STA must transmit this IE anyway. If the bits were placed in the HT IE location, then the field could be extended by one bit, and possibly even duplicated to differentiate
TX from RX. Make similar changes for TVHT, e.g. 8.4.2.170
|
|
|
3297
|
1032.10
|
10
|
8.4.2.157.3
|
Vinko Erceg
|
11-14/793r3
|
The universally complete set of architectures of 80+80 receivers does not imply support for certain capabilities when operating in 160 MHz mode as is already suggested by the existence of the Highest Supported Long GI Data Rate fields.
Some obvious combinations cannot currently be signaled. Also applies to TVHT (see, for example, 8.4.2.170)
|
Change the reserved field at bits 29-31 to become "Max NSS for 80+80 MHz" with the value in the field equal to nss supported for 80+80 MHz and a value of 0 to be used when 80+80 MHz is not supported. Change the reserved field at bits 61-63
to become "Max NSS for 160 MHz" with the value in the field equal to nss supported for 160 MHz and a value of 0 to be used when 160 MHz is not supported. Might also want to add a note saying that these values do not place an upper bound on the NSS supported
for 20, 40, 80 MHz - those bounds are specified elsewhere. Note that similar changes should be executed for TVHT.
|
See also 3298
|
|
3491
|
1032.10
|
10
|
8.4.2.157.3
|
Vinko Erceg
|
|
Some obvious combinations of 80+80 receivers cannot currently be signaled.
|
Reserved field at bits 29-31 SHOULD BE: "Max NSS for 80+80 MHz" with the value in the field equal to NSS supported for 80+80 MHz and a value of 0 to be used when 80+80 MHz is not supported. The reserved field at bits 61-63 SHOULD BE: "Max
NSS for 160 MHz" with the value in the field equal to NSS supported for 160 MHz and a value of 0 to be used when 160 MHz is not supported. Add note saying these values do not place an upper bound on the NSS supported for 20, 40, 80 MHz - those bounds are specified
elsewhere.
|
|
|
3489
|
1046.00
|
|
8.4.2.170
|
Vinko Erceg
|
|
For TVHT different number of segments supported may have different number of Nss supported. Allow for this flexibility.
|
As in comment. I will bring contribution.
|
|
|
3488
|
|
|
|
Vinko Erceg
|
|
In May 2014 IEEE 802.11 meeting, REVmc worked on a liaison letter from 3GPP. Throughput parameter was proposed to be used for network selection. However, this parameter needs to be defined in REVmc to be useful.
|
Define Throughput parameter in REVmc. I will bring contribution.
|
|
|
3487
|
1032.00
|
|
8.4.2.157.3
|
Vinko Erceg
|
|
VHT capabilities for BW and Nss are coupled. However, same Nss does not have to apply for 80MHz, 160MHz and 80+80MHz BW.
|
Use reserved bits B29-B31 to indicate Max Nss for 80+80MHz BW (0 indicates that 80+80MHz BW is not supported). Use reserved bits B61-B63 to indicate Max Nss for 160MHz BW (0 indicates that 160MHz BW is not supported).
|
|
|
3486
|
1029.00
|
|
8.4.2.157.2
|
Vinko Erceg
|
|
VHT capabilities for BW and Nss are coupled. However, same Nss does not have to apply for 80MHz, 160MHz and 80+80MHz BW.
|
Use B2-B3 bits to indicate if 80+80MHz or 160MHz BWs are used.
|
|
|
3477
|
1298.33
|
33
|
9.13.6
|
Vinko Erceg
|
11-14/1104r4
|
The second bullet appears to allow a VHT single MPDU (i.e. one with EOF = 1) to be followed by null subframes with EOF = 0. Once EOF has been signalled, it makes no sense to unsignal it (cf. 145.33)
|
Change "0 in the EOF field" to "the same value in the EOF field as the preceding A-MPDU subframe"
|
|
|
3673
|
1475.57
|
57
|
9.38.2.4
|
|
|
"Sector Sweep Feedback (SSW Feedback) occurs following each RSS.": is this just some naturally occuring phenonmenon? Need to indicate who issues the SSW Feedback frame, as well as the fact it is a frame.
|
Replace "(SSW Feedback) occurs following each RSS." with "(SSW Feedback) frame is issued by the STA after it completes each RSS."
|
EDITOR_Q: 2014-09-04 23:12:01Z - Need input from the domain experts. Transferred to MAC.
|
|
3674
|
1476.38
|
38
|
9.38.2.5
|
|
|
"When present, the Sector Sweep Ack (SSW-Ack) occurs following an SSW Feedback.": is this just a natural occurance? Need to indicate what STA issues this frame (and the fact that these two names are the names of frames).
|
Replace "(SSW-Ack) occurs following" with "(SSW-Ack) frame is issued after the STA receives an SSW Feedback frame."
|
Need inputs from domain experts. Transferred to MAC.
|