primitive:" -- OK, and how can the MLME determine the to deliver to the SME? 56 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 – TGax editor to make changes as shown in 11-17/1192r3 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. 55 11.46 Huge paragraph at P2049 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 "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 0 for the value of that parameter for that access category in the primitive. If the or Revise – TGax editor to make changes as shown in 11-17/1192r3 that are marked with CID 55
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 no need to have this seperate Clause. 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 such as is described in R.7. 2
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 – TGax editor to make changes as shown in 11-17/1192r3 that are marked with CID 31 30 Smith "A-MPDU aggregation is expected to be performed for 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 definition will eventually be placed into an MPDU of some sort
with a type of DATA and any of various subtypes. 212 Mark RISON "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 carrying Data of the corresponding AC for that STA." -- if you look at R.7 it turns out that this is exactly the time for the PPDUs, not including any contention/IFS time. This is a very subtle point (and differs from e.g. admission control) Change the cited text to "The Estimated Air Time Fraction subfield is 8 bits in length and contains an unsigned integer that represents the predicted percentage of air time (so not including interframe space), linearly scaled with 255 representing 100%, that a new STA joining the BSS will be allocated for PPDUs carrying Data of the corresponding AC for that STA (so not including any Management or Control frames)." Revise – TGax editor to make changes as shown in 11-17/1192r3 that are marked with CID 212 213 Mark RISON R.7 The equation for PPDU_Dur extremely pedantically accounts for symbol rounding ... and then completely fails to account for delimiters. It also includes the PHY header but not the PHY trailer (e.g. signal extension) At the end of the referenced subclause add a "NOTE---The equations above do not account for e.g. A-MPDU delimiters and signal extension." Revise – TGax editor to make changes as shown in 11-17/1192r3 that are marked with CID 213, which adds a minimum delimiter count of 4 octets to the PPDUDur equation, and adds a note that indicates that signal extension is not accounted for. 214 Mark R.7 The equation for PPDU_Dur assumes can be included in A-MPDUs, but this will only happen if both sides support it At the end of the referenced subclause add a "NOTE---The equations above assume that are included in Reject – there is a definition above the equation for A_MSDU_B which is based on a minimum function to determine the maximum mutual support for AMSDU.