MPDU count as an input. Therefore, an iterative calculation would be required and the complexity of such a description is not worth the slight change in accuracy of the result that would follow such a complex operation. R10: Description of Outbound Airtime Fraction – added a sentence that indicates that the value in the element might be different from what is actually experienced because the sending STA might have a different view of the medium condition than the receiving STA. R11: Global change of Estimated Service Parameters element to Estimated Service Parameters Inbound element Add ESP Outbound IE to Beacon frame format, probe request format, probe response format 9.4.2.216a Estimated service parameters outbound element – fix few field references 11.46 Estimated throughput – add paragraph for rules for inclusion of outbound element R.7 DPDUR – mentioned a recommended value for DPDUR for outbound calculation R12: CID 251 – added – same as CID 213 Updated document references R13: Slight change to wording of correspondence of outbound airtime bitmaps to outbound airtime information fields Changed the word “Airtime” in some field names to “Air Time” so that all such names use the two word version for consistency Updated document references R14: Slight change to wording of correspondence of outbound airtime bitmaps to outbound airtime information fields – lowest numbered bits stuff Qualifying some mesh STA references to “an ESP STA that is a mesh STA” Updated document references END OF REVISION NOTES Interpretation of a Motion to Adopt A motion to approve this submission that the editing instructions and any changed or added material are actioned in the TGax Draft. This introduction is not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGmd Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents). TGmd Editor: Editing instructions preceded by “TGmd Editor” are instructions to the TGmd editor to modify existing material in the TGmd draft. As a result of adopting the changes, the TGmd editor will execute the instructions rather than copy them to the TGmd Draft.
CIDs 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/1192r14 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)." Revise – TGmd editor to make changes as shown in 11-17/1192r14 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
The commenter intends to bring a related presentation. 55 Smith 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 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 Revise – TGmd editor to make changes as shown in 11-17/1192r14 that are marked with CID 55 Inbound
for an access category is equal to 0 in the primitive, the STA may use any value for the average MSDU size used in 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 Where 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 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/1192r14 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
is not expected to be performed for MSDUs for the corresponding AC". Seems to be missing something. Type subfield not equal to Data for the corresponding AC ." 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 – TGmd editor to make changes as shown in 11-17/1192r14 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 do not account for e.g. A-MPDU delimiters and signal extension." Revise – TGmd editor to make changes as shown in 11-17/1192r14 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. 4