|
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: 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.
|
|
3692
|
1525.13
|
13
|
10.1.4.3.3
|
Carlos Cordeiro
|
11-14/1594r0
|
"perform the basic access procedure defined ... prior to the transmission": as if we didn't know the definition was prior to the transmission. It also is unclear whether this procedure is to be followed just once or each time a Probe
Request frame is to be transmitted, and exactly why there may be more than one transmission of a Probe Request frame.
|
Since "prior to the transmission" is not part of the procedure defined in 9.3.4.2, this really is a run-on sentence. Replace "9.3.4.2 (Basic access) prior to the transmission of each of one or more Probe Request frames, each with an SSID
indicated in the SSID List and the BSSID from the MLME-SCAN.request primitive." with "9.3.4.2 (Basic access). Perform this procedure prior to each transmission of a Probe Request frame. Each of these transmitted Probe Request frames shall contain an SSID
that was included in the SSID List parameter and the BSSID from the BSSID parameter of the received MLME-SCAN.request primitive. One Probe Request frame shall be transmitted for each SSID included in the received SSID List parameter.".
|
MAC: 2014-12-22 19:04:48Z - Discussed on Dec 12. Carlos will bring back.
EDITOR: 2014-07-01 10:54:55Z - Was originally a Trivial Technical, but as it requires resolving a conflict in the number of probe responses, making this a technial and assigning to CarlosC.
|
|
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.
|
|
3211
|
2361.16
|
16
|
20.4.4
|
Mark Hamilton
|
11-14/1358r1
|
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).
|
|
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.
|
|
|
3508
|
711.05
|
5
|
8.4.2.3
|
Mark Hamilton
|
|
BSSMembershipSelector concept, added to Supported Rates element, really means the name "Suported Rates" is now misleading. Consider enhancing the name.
|
Change the element name from "Supported Rates" to "Supported Rates and PHYs"
|
EDITOR: 2014-12-15 06:26:42Z - Assigned to MAC
EDITOR: 2014-10-07 09:22:12Z - While agreeing with the concept, I don't think the resolution has enough detail to be workable. This term occurs in different contexts, and I'm not sure the same change is applicable to all. Also the concept of a "selector"
is not necessarily limited to PHY selection. It might be anything that we choose, such as support for extended block ack. Any name that attempts to explain this purpose is likely to be unweildy, and I recommend we create an abbreviation for this purpose
- e.g.
Support RBF, standing for "Rate and BSS Feature" or RBMS for "Rate and BSS Membership Selector".
Marking "Submission Required".
MGR: 2014-09-15 08:27:46Z - Is this changing the element name (throughout the spec) or actually the eponymous field in the element? What about Extended Supported Rates?
|
|
3364
|
|
|
|
Mark Rison
|
|
Requirements on BW for anything but RTS/CTS frames and first frame in TXOP re not clear
|
State that control responses can use any BSS bandwidth, but other frames (from either side) must obey the width set by RTS/CTS, where applicable
|
|
|
3365
|
1078.07
|
7
|
8.6.2.3.1
|
Mark Rison
|
11-14/1104r4
|
There appears to be nothing to ensure that the UPs in multiple TCLAS elements in ADDTS Request (and any other frame which can carry multiple TCLAS elements) specify the same UP
|
Add something to that effect somewhere
|
|
|
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
|
|
|
3439
|
1937.23
|
23
|
11.6.1.7.2
|
Mark Rison
|
11-14/1104r4
|
It is not specified how to convert from a character string to a bit string (8.2.2 says nothing about this)
|
Specify (a) the encoding (ASCII?) and (b) whether the string is to be considered to have a terminating NUL (the answer to this is probably no, given things like ""FT-R0" is 0x46 0x54 0x2D 0x52 0x30.") In turn, things like that quoted in
the previous parenthesis can be deleted
|
From teleconference:
Propose to reject as no technical issue is identified; many interoperable implementations are available.
Strings in 11r KDFs are all defined.
Assign back to Mark Rison, submission required, if change is still desired.
|
|
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.
|
|
3390
|
1315.57
|
57
|
9.22.2.8
|
Mark Rison
|
|
"3) A VHT MU PPDU carrying A-MPDUs to different users" -- wording is unclear
|
Change to "3) A VHT MU PPDU carrying single A-MPDUs to different users", matching 2) above
|
EDITOR_Q: 2014-09-04 00:07:57Z - the proposed change can be inferred from the text. I believe it to be a technical change. Transferred to MAC
|
|
3382
|
2814.53
|
53
|
C.3
|
Mark Rison
|
11-14/1104r4
|
dot11EDCATableTXOPLimit is not defined for Clause 20; dot11QAPEDCATableTXOPLimit is not defined for Clauses 20 or 21
|
Add references to these clauses to the description
|
|
|
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.
|
|
|
3231
|
1349.43
|
43
|
9.24.4
|
Qi Wang
|
|
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).
|
|
|
3460
|
1551.44
|
44
|
10.2.2.16.4
|
Qi Wang
|
|
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
|
|
|
3459
|
1551.21
|
21
|
10.2.2.16.3
|
Qi Wang
|
|
There is no single "Alternate Preferred" status
|
Refer to the two specific statuses from table 8-203
|
|
|
3138
|
1290.06
|
6
|
9.7.9
|
Ron Porat
|
|
For a TVHT STA, data rates available with non-HT PPDU are 6, 9, 12, 18, 24, 36, 48 and 54 Mb/s divided by 7.5 for 6 MHz and 7 MHz unit channels and by 5.625 for 8 MHz channels.
It is necessary to scale Non-HT reference rate in Table 9-7.
|
Insert a new bullet at the end of the 3rd paragraph of the subclause 4.3.13 as follows;
- non-HT data rate is divided by 7.5 for 6 MHz and 7 MHz unit channels and by 5.625 for 8 MHz channels.
|
|
|
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.
|
|
|
3008
|
1037.20
|
20
|
8.4.2.161
|
Ron Porat
|
|
According to 1037.59, the value 3 in Table 8-253 is reserved for TVHT STAs.
|
Indicate in table 8-253: "For VHT STAs, Local Maximum ... for 160/80+80 MHz. Reserved for TVHT STAs."
|
|
|
3007
|
1032.05
|
5
|
8.4.2.157.2
|
Ron Porat
|
|
"For a TVHT STA, support for Short GI is mandatory" -- this statement should not be in clause 8.
Also "support is mandatory" is being replaced stylistically with "A TVHT STA shall support Short GI".
|
Move statement out of clause 8 and reword as proposed, or delete if it is a duplicate.
|
|
|
3032
|
1682.34
|
34
|
10.16.12
|
Vinko Erceg
|
|
"A VHT STA is not required to perform any of the behavior described in this subclause associated with
Information Request and 20 MHz BSS Width Request" -- this statement either has no effect, or creates internal contradictions with "an HT STA shall" statements in this subclause.
|
Identify the exceptions in this subclause and replace "<a type of HT STA>..." with "<a type of HT STA> that is not a VHT STA..." where <a type of HT STA> might include things like "40MC HT AP 2G4" and similar abominations.
|
|
|
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.
|
|
|
3296
|
1029.47
|
47
|
8.4.2.157.2
|
Vinko Erceg
|
|
The universally complete set of architectures of 80+80 receivers does not imply support for 160 MHz operation as is already suggeted by the current definitions of the values for 1 and 2. I.e. support for 160 does not imply support for 80+80
and similarly, support for 80+80 does not imply support for 160. I.e. the case for 80+80 only support is missing. Same comment for TVHT (see 8.4.2.170)
|
Change "The value of 3 is reserved" to "Set to 3 if the STA supports 80+80 MHz mode and not 160 MHz" Change "Set to 1 if the STA supports 160 MHz" to "Set to 1 if the STA supports 160 MHz and not 80+80 MHz" - similar request for change
to TVHT equivalent structures.
|
|
|
3295
|
1032.10
|
10
|
8.4.2.157.3
|
Vinko Erceg
|
|
The architecture of an 80+80 MHz receiver does not imply support for certain capabilities when operating in 60 MHz mode as is already suggeted by the existence of the Highest Supported Long GI Data Rate fields. Some obvious combinations
cannot currently be signaled.
|
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.
|
|
|
3294
|
1029.47
|
47
|
8.4.2.157.2
|
Vinko Erceg
|
|
The architecture of an 80+80 receiver does not imply support for 160 MHz operation as is already suggeted by the current definitions of the values for 1 and 2. I.e. support for 160 does not imply support for 80+80 and similarly, support
for 80+80 does not imply support for 160. I.e. the case for 80+80 only support is missing.
|
Change "The value of 3 is reserved" to "Set to 3 if the STA supports 80+80 MHz mode and not 160 MHz" Change "Set to 1 if the STA supports 160 MHz" to "Set to 1 if the STA supports 160 MHz and not 80+80 MHz"
|
|
|
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"
|
|
|
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.
|
|
|
3490
|
1029.47
|
47
|
8.4.2.157.2
|
Vinko Erceg
|
|
The case for 80+80 support is missing. Support for 80+80 does not imply support for 160 and support for 160 does not imply support for 80+80. and similarly, support for 80+80 does not imply support for 160.
|
Change "The value of 3 is reserved" to "Set to 3 if the STA supports 80+80 MHz mode and not 160 MHz". IS: "Set to 1 if the STA supports 160 MHz" SHOULD BE: "Set to 1 if the STA supports 160 MHz and not 80+80 MHz"
|
|
|
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.
|
|
|
3385
|
1032.07
|
7
|
8.4.2.157.3
|
Vinko Erceg
|
|
Not clear whether the Supported VHT-MCS and NSS Set field refers to per-user or total N_SS, in the case of MU-MIMO
|
Suggest it be per-user
|
|
|
3226
|
1805.23
|
23
|
10.33.2.2
|
|
|
Consider using PPDU
|
"... any other individually addressed PPDUA-MPDU, MPDU, or MMPDU to the responder ..."
|
EDITOR: 2014-09-05 12:12:45Z - This is not an editorial change. I would note that "individually addressed PPDU" is meaningless. Transferring 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.
|
|
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.
|
|
3462
|
|
|
|
|
|
"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.
|
|
3430
|
1862.56
|
56
|
11.3.5.4
|
|
|
Having more than one thing (e.g. "KCK || PMK") on the left of an equals sign is somewhat confusing
|
Use L() as in 11.6.1.3
|
EDITOR: 2014-11-19 14:11:42Z -
Somehow, had failed to make the transfer. Transferred to MAC, really!
EDITOR: 2014-10-23 15:27:48Z -
This requires a technical interpretation of the meaning of these symbols. Transfer to MAC.
Note the resolution "Replace "KCK || PMK" with "(KCK || PMK)"." has been speculatively edited.
MGR: 2014-09-17 06:41:02Z - That doesn't really help address the confusion. As the proposed change says, you need to use L() as in 11.6.1.3, i.e. blah = KDF-512(zoo,zah,zing), KCK = L(blah, foo, bar), PMK = L(blah, baz, boing)
|