|
Context: 1259.13:
9.3.6 Group addressed MPDU transfer procedure
When a STA transmits group addressed MPDUs in which the To DS field is 0, the STA shall use the basic access procedure, unless these MPDUs are delivered using PCF or using the group addressed transmission service (GATS). When group addressed MPDUs are not delivered using GATS, no RTS/CTS or RTS/DMG CTS exchange shall be used, regardless of the length of the frame. In addition, no Ack frame shall be transmitted by any of the recipients of the frame. Any group addressed MPDUs in which the To DS field is 1 transmitted by a STA shall, in addition to conforming to the basic access procedure of CSMA/CA, obey the rules for RTS/CTS exchange and the Ack procedure because the MPDU is directed to the AP. For DMG STAs, the MPDU transmission shall also conform to the access procedures defined in 9.36 (DMG channel access). When dot11SSPNInterfaceActivated is true, an AP shall distribute the group addressed message into the BSS only if dot11NonAPStationAuthSourceMulticast in the dot11InterworkingEntry identified by the source MAC address in the received message is true. When dot11SSPNInterfaceActivated is false, the group
addressed message shall be distributed into the BSS.Unless the MPDU is delivered via DMS, the STA
originating the message receives the message as a group addressed message (prior to any filtering). Therefore, a STA shall filter out group addressed messages that contain their address as the source address. When dot11SSPNInterfaceActivated is false, group addressed MSDUs shall be propagated throughout the ESS. When dot11SSPNInterfaceActivated is true, group addressed MSDUs shall be propagated throughout the ESS only if dot11NonAPStationAuthSourceMulticast in the dot11InterworkingEntry identified by the source MAC address in the received message is true.
|
New home:
The MAC data service provides the transport of MSDUs between MAC peer entities as characterized in 5.1.1 (Data service).
The transmission process is started by receipt of an MA-UNITDATA.request primitive containing an MSDU and the associated parameters. This might cause one or more (#100)Data (Ed)frames containing the MSDU to be transmitted following A MSDU aggregation, fragmentation, and security encapsulation, as appropriate.
The MA-UNITDATA.indication primitive is generated in response to one or more received (#100)Data (Ed)frames containing an MSDU following validation, address filtering, decryption, decapsulation, defragmentation, and A MSDU deaggregation, as -appropriate.
When dot11SSPNInterfaceActivated is true, an AP shall distribute the group addressed message into the BSS only if dot11NonAPStationAuthSourceMulticast in the dot11InterworkingEntry identified by the source MAC address in the received message is true. When dot11SSPNInterfaceActivated is false, the group addressed message shall be distributed into the BSS.Unless the MPDU is delivered via DMS, the STA originating the message receives the message as a group addressed message (prior to any filtering). Therefore, a STA shall filter out group addressed messages that contain their address as the source address. When dot11SSPNInterfaceActivated is false, group addressed MSDUs shall be propagated throughout the ESS. When dot11SSPNInterfaceActivated is true, group addressed MSDUs shall be propagated throughout the ESS only if dot11NonAPStationAuthSourceMulticast in the dot11InterworkingEntry identified by the source MAC address in the received message is true.
Address filtering is performed on the Address 1 field of each MPDU contained in a PPDU and on the DA of each MSDU within an A-MSDU. When the Address 1 field or DA field contains a group address, address filtering is performed by comparing the value in the Address 1 field or DA field to all values in the dot11GroupAddressesTable, and the STA also validates the BSSID to verify either that the group addressed frame originated from a STA in the BSS of which the receiving STA is a member, or that it contains the wildcard BSSID value, indicating a (#100)Data frame sent outside the context of a BSS (dot11OCBActivated is true in the transmitting STA).(#2452)
A mesh STA also uses the address matching rules described in Error: Reference source not found, when it receives an individually addressed frame. When a mesh STA receives a frame with the Address 1 field equal to a group address, the mesh STA also checks the TA to determine whether the group addressed frame originated from one of its peer mesh STAs; if there is no match, the STA shall discard the frame.(#1255) A mesh STA also uses the address matching rules described in Error: Reference source not found.(#2452)
If the Address 1 field of an MPDU carrying an A-MSDU does not match any individual address at a receiving STA, then the entire A-MSDU is discarded.(#2452)
In a QoS STA, the TID parameter of the MA-UNITDATA.request primitive results in a TID being specified for the transmitted MSDU. This TID associates the MSDU with the AC or TS queue for the indicated traffic.
|
Proposed Resolution:
Accepted.
3017
|
1273.28
|
9.7.1
|
"The Duration/ID field in a frame transmitted by a QoS STA may cover multiple frames and may involve using the PLME-TXTIME.request primitive several times." -- I think "may involve" should be "might involve", otherwise we are attempting to permit "involvement".
|
Change "may involve" to "might involve" at cited location.
|
Proposed resolution:
Accepted
3021
|
1282.39
|
9.7.6.5.3
|
"moreover" is archaic and unnecessary
Ditto at line 50
|
Replace "Moreover, eliminate" with "Eliminate"
|
Context: 1282.39:
Eliminate from the CandidateMCSSet all tuples. Moreover, eEliminate all
MCSs that have a data rate greater than the data rate of the received PPDU (the mapping of
MCS to data rate is defined in 20.5 (Parameters for HT MCSs)).
[snip]
Eliminate from the CandidateMCSSet all tuples. Moreover, eEliminate all
MCSs that have an index that is higher than the index of the MCS of the received frame. Also
eliminate all MCSs that have a number of spatial streams greaterthan that indicated in the Rx
NSS subfield in the most recent Operating Mode field with the Rx NSS Type subfield equal to
0 from the intended receiver STA,if at least one Operating Mode field with the Rx NSS Type
subfield equal to 0 was received from the intended receiver STA.
|
Proposed Resolution:
Accepted
3022
|
1284.39
|
9.7.6.6
|
"NOTE 1--The rules in this subclause, combined with the rules in 9.7.6.1 (General rules for rate selection for Control frames), determines the formatof control response frames." -- It is odd to start a subclause with a note! As this is generally commentary on the preceding para.
|
Promote note to a body para.
|
Proposed Resolution:
Revised. Remove “NOTE 1--” and renumber subsequent notes. Change format to body text.
3498
|
1353.34
|
10.1.2.1
|
AP and PCP are not STAs, they contain STAs.
|
Replace "A STA that is the AP or the PCP shall ..." with "A STA contained in the AP or PCP shall ..."
|
Proposed Resolution:
Accepted.
(Note that the correct location for this change is 1513.34.)
3026
|
1380.44
|
9.27.9
|
"Subelement information is listed in Table 8-91 (Optional subelement IDs for Channel Load request), Table 8-93 (Optional subelement IDs for Noise Histogram Request), ... " -- Listing these tables here is unnecessary, and will probably get out of date.
Further, I see confusion about where subelement IDs are defined. This can be clarified.
|
Replace "Subelement information is listed in Table 8-91 (Optional subelement IDs for Channel Load request), ... and Table 8-295 (Optional subelement IDs for Measurement Pilot frame). These subelement tables indicate"
with:
'Subelements are defined locally in each subclause that defines a structure containing subelements. Subelement ID numbering is private to that structure. Subelement IDs are defined in a table that includes an "Extensible" column. This column indicates'
|
Context: 1380.27: (and proposed change)
-
Extensible subelement parsing
A subelement has the structure defined in 8.4.3 (Subelements) and is contained within an element or subelement.
A STA that encounters an unknown, unsupported, or reserved subelement ID value contained in an element or subelement shall ignore the subelement with that subelement ID value and shall continue to parse any remaining element or subelement body for additional subelements with recognizable subelement ID values.
A STA that receives an element or subelement for which a vendor-specific subelement is defined and that contains a vendor-specific subelement that it does not support shall ignore this vendor-specific subelement and shall continue to parse any remaining element or subelement body for additional subelements with recognizable subelement ID values.(#2185)
-
Listing these tables here is unnecessary, and will probably get out of date.
Subelement information is listed in Table 8-91 (Optional subelement IDs for Channel Load request), Table 8-93 (Optional subelement IDs for Noise Histogram Request), Table 8-96 (Optional subelement IDs for Beacon Request), Table 8-99 (Optional subelement IDs for frame request), Table 8-101 (Optional subelement IDs for STA Statistics request), Table 8-103 (Optional subelement IDs for LCI request), Table 8-104 (Optional subelement IDs for Transmit Stream/Category Measurement Request), Table 8-106 (Optional subelement IDs for measurement pause request), Table 8-117 (Optional subelement IDs for Channel Load report), Table 8-119 (Optional subelement IDs for Noise Histogram report), Table 8-120 (Optional subelement IDs for Beacon report), Table 8-121 (Optional subelement IDs for Frame report), Table 8-123 (Optional subelement IDs for STA Statistics report), Table 8-124 (Subelement IDs for Location Configuration Information Report), Table 8-126 (Optional subelement IDs for Transmit Stream/Category Measurement report), Table 8-158 (Optional subelement IDs for neighbor report), Table 8-160 (Optional subelement IDs for Measurement Pilot Transmission), Table 8-163 (Optional subelement IDs for Multiple BSSID), and Table 8-295 (Optional subelement IDs for Measurement Pilot frame). These subelement tables indicate Subelements are defined locally in each subclause that defines a structure containing subelements. Subelement ID numbering is private to that structure. Subelement IDs are defined in a table that includes an "Extensible" column. This column indicates which subelements are considered extensible in future revisions of the standard, by placing a Yes in the Extensible column. A STA that receives an extensible subelement in which the Length field exceeds the value indicated in the subelement tables shall discard any part of the subelement beyond the maximum length indicated in the subelement tables and shall otherwise process the subelement as though this truncated subelement had been received.
|
Proposed Resolution:
Accepted.
3667
|
1399.63
|
9.32.2.1
|
"use only HT and non-HT PPDUs": uhh, are there any other kinds of PPDUs? Since the sentence is about HT procedures, should "and non-HT" be deleted?
|
Delete "and non-HT".
|
Discussion:
An HT PPDU is defined as: 31.43
high throughput (HT) physical layer (PHY) protocol data unit (PPDU): A Clause 20 (High Throughput (HT) PHY specification) PPDU with the TXVECTOR FORMAT parameter equal to HT_MF or HT_GF.
|
A non-HT PPDU is defined as:
non-high throughput (non-HT) physical layer (PHY) protocol data unit (PPDU): A Clause 20 (High
Throughput (HT) PHY specification) physical layer (PHY) PPDU with the TXVECTOR FORMAT
parameter equal to NON_HT
|
And the TXVECTOR FORMAT parameter is:
Determines the format of the PPDU.
Enumerated type:
NON_HT indicates Clause 16 (DSSS PHY specification for the
2.4 GHz band designated for ISM applications), Clause 18
(Orthogonal frequency division multiplexing (OFDM) PHY
specification), Clause 17 (High rate direct sequence spread spectrum
(HR/DSSS) PHY specification), or Clause 19 (Extended Rate PHY
(ERP) specification) PPDU formats or non-HT duplicate PPDU
format. In this case, the modulation is determined by the
NON_HT_MODULATION parameter.
HT_MF indicates HT-mixed format.
HT_GF indicates HT-greenfield format.
|
So HT and non-HT PPDUs are the only things understood by an HT STA, and the qualifications is aparently unnecessary.
However, I believe this was added by .11ac, in order to exclude the use of a VHT PPDU. That only makes sense
if this subclause was also used by a VHT STA.
Status:
I think this is not a trivial technical comment, and request it be classified as PHY (VHT).
3095
|
1488.05
|
9.38.6.2
|
" If there is not sufficient time left in the allocation for the completion of the SSW Feedback and SSW-Ack," -- what does "completion" of a frame mean?
|
"completion" -> "transmission"
|
Context: 1488.01:
The initiator shall begin an SSW Feedback (9.38.2.4 (Sector Sweep Feedback)) MBIFS time following the completion of an RSS, provided the initiator received an SSW frame from the responder during the RSS and there is sufficient time left in the allocation to complete the SSW Feedback followed by an SSW-Ack (9.38.2.5 (Sector Sweep Ack)) from the responder in MBIFS time. If there is not sufficient time left in the allocation for the completion of the SSW Feedback and SSW-Ack, the initiator shall begin the SSW Feedback at the start of the following allocation between the initiator and the responder.
|
Discussion:
There are a number of issues, including the one cited. What is an “SSW Feedback”? Is it the field, frame or the phase?
I have highlighted undefined terms above.
Status: Asked Carlos C for comment.
3681
|
1524.04
|
10.1.4.3.2
|
"is present in the MLME-SCAN.request primitive": unfortunately, parameters are never inside a primitive. But they might be used in the _invocation_ of a primitive.
|
Replace with "parameter is present in the invocation of the MLME-SCAN.request primitive".
|
Proposed Resolution:
Revised. Make change as indicated and make matching changes at 1525.12 and 1525.22.
3692
|
1525.13
|
10.1.4.3.3
|
"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.".
|
Context:
In all these cases, the probe request is sent with the SSID and BSSID from the MLMESCAN.request primitive. The probe request includes the DMG Capabilities element. When the SSID List is present in the MLME-SCAN.request primitive, perform the basic access procedure defined in 9.3.4.2 (Basic access) prior to the transmission of each of the one or more Probe Request frames, each with an SSID indicated in the SSID Listand the BSSID from the MLME-SCAN.request primitive.
|
Discussion:
There appears to be an inconsistency in the numbering of the probe requests.
Status: not trivial technical. Assigning to CarlosC.
3693
|
1525.18
|
10.1.4.3.3
|
Per the Style Manual,"shall"/"should"/"may" are to be used to express normative statements.
|
Replace "optionally send" with "the STA may transmit".
|
Discussion:
Agree with the intent. Note the proposed resolution rewords “transmit” to “send”. As the two are synonyms (600 “sends” and 3200 “transmits), this change is unnecessary, and conflicts with style at 1525.01.
Proposed resolution:
Revised. Replace “optionally send” with “the STA may send”.
3117
|
1531.24
|
10.2.1
|
Reference is to Table 8-85 (Element IDs) yet we have Table 10-1 in this clause which is not referred to. Confusing. Table 8-85 does not categorize the frames as bufferable or not, this is Table 10-1.
|
Change "Management frames are categorized as bufferable or nonbufferable, as shown in Table 8-85 (Element IDs)." to "Management frames, as shown in Table 8-85 (Element IDS) are categorized as bufferable or nonbufferable, as shown in Table10-1."
|
Dostları ilə paylaş: |
