259 Mark RISON 11.46 "When an primitive is received at the MLME, the MLME can use the parameters provided in the primitive plus the following information to create estimates of throughput per access category to deliver to the SME in the parameter of the primitive:" -- OK, and how can the MLME determine the to deliver to the SME? Add an equivalent para for Revise – TGmd editor to make changes as in 11-17/1192r13 that are marked with CID 259 56 Smith 11.46 This "Estimated Throughput" is intended to be useful for controlling traffic decisions. It does specify how a STA can inform another STA of traffic estimates but I am not convinced that this is of any use for what it supposed to address. By stating at L51 and L53 that these outside entities "need to know the current estimates" we are open to questions of accuracy and 'how to use'. I suggest that these statements are removed. Delete "Entities outside the scope of this standard that might control the traffic steering decision of a device benefitby being able to predict the throughput that might be obtained through a link with a STA. Those same entities also need to know what the current estimate of throughput is for network selection purposes (by comparing an estimated throughout with existing throughout)." The commenter intends to bring a related presentation. Revise – TGmd editor to make changes as shown in 11-17/1192r13 that are marked with CID 56 – slight modifications to the wording have been made to reduce the expressed level of certainty of the statements as opposed to the wholesale deletion proposed by the commenter, based on the fact that existing systems do use parameters similar to those listed to make the decisions described in the cited text. EstimatedThroughput 0
55 Smith 11.46 Huge paragraph at L13 is in fact quite simple", but is repeated for each parameter and hence becomes diffivult to comprehend. If the MLME is incapable of determining a vale for it simply returns a 0. If the AverageMSDU size in the primitive is -1, then the corresponding the primitive is 0. If the AverageMSDU size is 0, then the correspondoing EstimatedThroughput is calculated using any size but recommends 1500B. Can we try to write it simpler? "If the MLME is incapable of determining a value for the or parameter for any access category, then the MLME shall return a value of for the value of that parameter for that access category in the primitive. If the or parameter for an access category is equal to -1 in the primitive, the STA shall include a value of 0 in the respective or parameter for the corresponding access category in the primitive. If the or parameter for an access category is equal to 0 in the primitive, the STA may use any value for the average MSDU size used in Revise – TGmd editor to make changes as shown in 11-17/1192r13 that are marked with CID 55 Inbound
calculating the estimated throughput to be included in the corresponding access category in the respective or parameter of the primitive, but should use a value of 1500 octets. " 54 Smith 11.45 did this "Beacon RSSI" come from (shame on me for missing it) ? What is it used for? I see no dirrect reference to using it anywhere, unless it is P2049L1, and if so why a seperate clause??. Also +/-5dB is useless, differing MCS EVM requirements are much tighter than 5dB, it needs to be +/-1dB. We need to tighten up on all these RSSI measurements, there is no reason why we need to stick to +/- 5dB we should be making a target of 1dB. As many will know I have been advocating the DSC mechanism that uses the Beacon RSSI. As such an algorithm for determining the Beacon RSSI has been presented that accounts for a mobile STA, missed beacons etc. but uses the Beacon RSSI to adjust effective CCA thresheld. This is a good use for Beacon RSSI but even if DSC is adopted there is still Either change 5dB to 1dB, or delete this clause and all references to dot11BeaconRssi Revise – TGmd editor to make changes as shown in 11-17/1192r13 that are marked with CID 54, commenter to see 11.45 Beacon RSSI. Accuracy value was agreed upon by discussion among PHY experts. Again, this parameter is already successfully used today in existing systems and while the accuracy might not be as high as desired, experts did not agree that a more accurate value was possible and useful output is generated in real systems with an accuracy estimated to be about 5dB. Commenter can review equation of Annex R.7 P3801 to see where RSSI is used, noting that in the earliest implementations, a simple comparison of RSSI is often employed rather than a calculation 2
no need to have this seperate Clause. such as is described in R.7. 31 Smith "The Estimated Air Time Fraction subfield is 8 bits in length and contains an unsigned integer that represents the predicted percentage of time, linearly scaled with 255 representing 100%, that a new STA joining the BSS will be allocated for PPDUs that contain only MPDUs with the Type subfield equal to Data of the corresponding access category for that STA." "Allocated"? So the STA is using HCCA, or EDCA Admission Control? What scheme is in use here that we have allocation of BW to specific STAs, and traffic? In addition, what is %, the fraction of all traffic or fraction of just that AC traffic? This is unclear, but why have this for every AC and how is this to be interpreted? Also unclear how an AP would even measure this. I am generally unhappy with this, I might make a presentation. Replace with "The Estimated Air Time Fraction subfield is 8 bits in length and contains an unsigned integer that represents the predicted percentage of time, linearly scaled with 255 representing 100%, not used by PPDUs that contain only MPDUs with the Type subfield equal to Data, of the corresponding access category." Revise – TGmd editor to make changes as shown in 11-17/1192r13 that are marked with CID 31 30 "A-MPDU aggregation is expected to be performed for MPDUs with the Type subfield equal to Data for the corresponding AC, but A-MSDU aggregation is not expected to be performed for MSDUs for the corresponding AC". Seems to be missing something. Change cited text after the comma to "but A-MSDU aggregation is not expected to be performed for MSDUs with the Type subfield not equal to Data for the corresponding AC ." Reject – nothing is missing. MPDUs are aggregated into AMPDUs, and MPDUs have a MAC header with a type and subtype and TID. A-MSDUs are built from MSDUs which do not have a MAC header and therefore do not have type or subtype but by 4 4
A_MSDU_BRX to account for the case of no aggregation. 215 Mark RISON R.7 PPDU_Dur "is the expected duration of a single PPDU, in seconds". DPDUR "is the Data PPDU duration target of the transmitter of the PPDUs containing MPDUs with the Type subfield equal to Data, in seconds". Given the equation, PPDU_Dur is also only for PPDUs with Data MPDUs. So PPDU_Dur is the same thing as DPDUR Delete the definition of PPDU_Dur and then change PPDU_Dur to DPDUR throughout the referenced subclause Revise – TGmd editor to make changes as in 11-17/1192r13 that are marked with CID 215, which makes a reference to the Data PPDU Duration Target subfield of the ESP element, while noting that the two terms cited by the commenter, PPDU_Dur and DPDUR are not the same thing. DPDUR is the target duration, but PPDU_Dur is the actual duration which can be limited at high data rates by aggregation limits, for example. 216 Mark RISON R.7 "Note that some of the parameters of Equation (R-2) have values that are AC dependent." -- er, which? None of them have any dependency on the AC Delete the sentence Accept. 217 Mark Rison R.7 It is claimed that one can determine and for each AC of a current or potential link to another STA using Equation (R-1)", but Equation (R-1) refers to EST_AirtimeFraction, which is defined as " the estimated portion of airtime that is available for outbound transmissions", so does not work for inbound traffic Delete and" in R.7. At the end of R.7 add a para "The mechanism by which ESP STAs determine values for is outside the scope of the standard." Revise – TGmd editor to make changes as shown in 11-17/1192r13 that are marked with CID 217, which generally agree with the nature of the comment, but resolve it by adding language for describing a method for estimating the inbound traffic. Outbound