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 shown in 11-17/1192r4 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 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 in 11-17/1192r4 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/1192r4 that are marked with CID 55 Inbound Outbound
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/1192r4 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 cited 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/1192r4 that are marked with CID 31 30 Smith "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. 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