| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
As regards feasibility and accuracy of the throughput estimates, the following 11mc SB comments may be relevant:
Mark -- Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From: Thomas Derham [mailto:thomas.derham@xxxxxxxxxxx]
Hi George Thanks. Couple more comments inline [TD2]: From: George Calcev [mailto:George.Calcev@xxxxxxxxxx]
Hi Thomas, Thanks for your comments. See my reply inline as well. Cheers, George From: Thomas
Derham [mailto:thomas.derham@xxxxxxxxxxx]
Hi George Thanks for sharing your thoughts and the good discussion. Some follow up comments inline below: From: George
Calcev [mailto:George.Calcev@xxxxxxxxxx]
Hello Thomas , Thank you for your thoughts. I think that the questions from 3GPP are very clear and simple and that they expect that
we address them in the same manner. I think that we should focus on providing them clear and prompt information.
Here is my 2c for the answers. 1)
IEEE802.11 spec does not provide any accuracy requirement or specifications for “Estimated Throughput” [Thomas] Estimated Throughput is defined in the specification. Therefore we should not say there is not [a] specification
for it. [George] OK 2)
IEEE802.11 cannot provide any bound for the variation between various implementations.
[Thomas] Again, I believe some explanation is required to avoid misleading conclusions to be drawn from such statement. [George] What do you mean by misleading conclusion. This just states a fact, not a conclusion. [TD2] A misleading conclusion could be that the metric cannot be trusted. An explanation could, at the least, explain the reason why
the spec does not provide absolute accuracy bounds. If we wanted to be more helpful, we could perhaps even propose 3GPP investigate other mechanisms (e.g. test cases, most likely developed outside 802.11) by which the validity of the metric generated by implementations
could be tested. 3)
Feasibility of “Estimated throughput” (thanks for your inputs): REVmc does define a possible mechanism to allow a STA to estimate
the possible throughput [Thomas] REVmc states use of the equation is a “should”, so I think it is stronger than a “possible” mechanism. We can
just say that, according to spec, a STA “should” use that mechanism [George] I am OK with the term “should” as mentioned by our spec, however this indicates a recommendation not a mandate.
Let be clear. [TD2] OK as a “ derived metric “ that should be calculated from other estimates such as the air fractional
time (Annex R7). There is no explicit mechanism to allow an AP STA to have a DL estimate (your response); one could use the equations in Annex R7 as a reference.
[Thomas] OK However, 3GPP should keep in mind that such estimations in unlicensed band could be highly
volatile depending on multitude factors such as changes in the environment, traffic of the surrounding STAs and OBSSs, mobility, and eventually will depend on the actual implementation of the estimators.
[Thomas] I disagree with this sentence. There is nothing in spec or in IEEE’s experience from which we should assume
the metric is “highly volatile”. And there is no reason why this metric should be any more volatile than other metrics 3GPP is already using (e.g. Channel Occupation). The relationship with unlicensed spectrum also seems tenuous – load on licensed spectrum
may dynamically vary too. [George] Thomas, I would be very happy to see any validation of the Annex recommended formula. I am not aware of any
such measurement, deployment or realistic simulation to show the validity and consistence of the estimator in WLAN dense environment. Thanks. [TD2] If there are simulation/deployment results that demonstrate validity of the metric then I agree they would be useful inputs
in a response. In the absence of such results, while I agree we should not make a guarantee of reliability, nor should we speculate on any potential deviance of that reliability. Preferably, as mentioned above, we could provide useful input on how implementations
could be validated even in the absence of explicit accuracy requirements in the specification. 4)
Historically, IEEE 802.11 does not define requirements for the accuracy of the performance measurements/reports.
[Thomas] Well, there is a requirement for accuracy of Beacon RSSI in REVmc, for example. There is no current activity dedicated to such definition for the “Estimated Throughput”.
[Thomas] That may be true, but for the reasons previously described, I think it is missing the point. [George] I think that the point is that 3GPP is expecting from us accurate metric definitions that could be used consistently
for their LWA purpose. Again, it is just states the fact, nothing else. 5)
Because LWA was developed in 3GPP, I think that 3GPP should provide us their requirements for the metrics/measurements necessary
for LWA usage. I do not think that we should speculate on what would be the right measurements for them and how they will be used by 3GPP, it is not efficient and potentially would delay considerably our LS. If they will provide us their requirements (at
a later date), then we could decide if solutions for such requirements are possible in IEEE802.11 and what are those. [Thomas] I have no problem with asking 3GPP to provide more details of their requirements, indeed I think such text
has been proposed. I do however believe we do not yet have a common view on how we wish to articulate the characteristics of our own feature – that is something that needs to be clarified before a response is sent which could be misleading. [George] My point is that we should articulate the characteristics of our own feature based on the use case requirements,
as we usually do in 802.11, and I think that at this time we do not have such requirements. [TD2] If that is the case, then we should figure out the requirements before we even begin to articulate a response. Best regards, George . From: Thomas
Derham [mailto:thomas.derham@xxxxxxxxxxx]
Hi Mark, Joe, Laurent, Youhan Thanks for the discussion. Some comments as follows: 1) Regarding Mark's comment on pre/post-activation The original LS from RAN2 says: > 3GPP RAN2 is considering to
use the WLAN “Estimated Throughput” where it is reported to the eNB for LWA operation (e.g. activation and deactivation of LWA and data forwarding decisions at the eNB). My understanding is that the "pre-activation" and "post-activation" phases referred to in the draft text refer to the two cases in parentheses
above. i.e. "pre-activation" means "[decision to] activat[e] ... LWA", while "post-activation" means both "data forwarding decisions at the eNB" and "deactivation of LWA", If it is confusing, we could use terminology that maps better to the original language in the LS. I think it is useful to differentiate between
the two usages in the responses we give to the five questions, where needed. 2) Regarding Mark's comment on calculation of the metric in both directions My understanding is that REVmc does now define a mechanism by which the AP can obtain (ESP) information to allow an uplink estimate to be
calculated. Specifically, transmission of ESP parameters by a non-AP STA is defined in D8.0 11.46. On the other hand, I believe the downlink measurement is the most practical and important in LWA use case, and will usually be reasonably correlated with the
uplink measurement, especially in the case of 11ax. We may want to think about the most useful and accurate language to respond to this part of the request. 3) Regarding Laurent and Youhan's comment about calculation of downlink measurement by the AP I also agree that in principle a downlink estimate could be calculated by the AP. It would need to estimate, by whatever means, certain parameters
(e.g. downlink RSSI) that the STA would know, so in general may not be as accurate as a calculation by the STA. I agree with Youhan that there is no explicit support provided in the spec for an AP to do this (e.g. no need to transmit ESP element); on
the other hand, the equation in Annex R.7 could be used as a reference. 4) Regarding the current draft, and a response to question 4 I agree with Mark that a response should be provided to question 4. I also believe question 1 and 4 are strongly related and should be answered
together. The metrics used to date by 3GPP (e.g. RSSI, Channel Utilization) have been explicit measurements, where the measurement method and/or accuracy
bounds are specified in 802.11 specification. On the contrary, Estimated Throughput is a *derived metric", which should be calculated (per Annex R.7) based on a combination of internal measurements (e.g. RSSI), expected operational parameters (e.g. BA window
size, PPDU duration) and other derived values indicated by the transmitting devices (notably, Estimated Air Time Fraction in the ESP element). To my understanding, the motivation for defining the Estimated Air Time Fraction is to allow the transmitting device
to provide a concise and sufficient indication of its expected ability to transmit to the STA. It should be evident that, in the general case, this value is not a simple measurement, and indeed the advantage it can have (e.g. over Channel Utilization) is that
it can also encapsulate the transmitting device's state (e.g. transmit queue, scheduling policy), its knowledge of channel activity, etc. Therefore, it is probably not practical to define explicit accuracy bounds in the specification in the same way as is done for basic measurements.
On the other hand, there can be various other mechanisms whereby 3GPP could ensure the validity of the metric transmitted by devices, if they so-choose. I believe this basic concept was reasonably captured in 16/1517r0, and (imho) it is rather unhelpful that it has been removed in the current
draft. We cannot expect to be asked the same question multiple times, so if we provide a response I believe it should be a constructive and useful
one. The current draft "[spec] does not provide any specification for ... accuracy..." does not say anything more than could be surmised by someone browsing
the spec by themselves. I would suggest that, if more discussion is needed to produce and agree a response that we expect to be valuable to 3GPP, we take the time
to do so properly. Best wishes From:
Mark Rison <m.rison@xxxxxxxxxxx> I am a bit confused by the draft reply. The request was for feedback on: 1) whether there are any accuracy requirements for “Estimated Throughput”, 2) “Estimated Throughput”'s variations across different implementations 3) feasibility of “Estimated Throughput” calculation by either STA or AP 4) if it would be feasible for IEEE to define “Estimated Throughput” accuracy requirements, if not already defined 5) other metrics which can also be useful for LWA operation The draft reply addresses 1 and 2. It does not address 3 or 4 and mentions but does not really address 5. Conversely, it goes into discussion of "pre-activation
and post-activation phases of LWA" which does not in any obvious way relate to the 5 requests made. Incidentally, as regards 3 and 4, the ESTT mechanism was examined during TGm sponsor ballot comment resolution, and the conclusion was that it is not feasible to calculate in one direction (I forget which) because required information is missing, and the calculations in R.7 are inaccurate anyway. Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From:
Levy, Joseph S [mailto:Joseph.Levy@xxxxxxxxxxxxxxxx]
An updated Draft Reply to Liaison from 3GPP RAN2 on Estimated Throughput (11-16-1384) is available:
https://mentor.ieee.org/802.11/dcn/16/11-16-1510-01-AANI-reply-to-liaison-from-3gpp-ran2-on-estimated-throughput-11-16-1384.docx This document is the result of the drafting session held during the AANI SC EVE session 8 November 2016.
Please review and comment. The intent is to present this liaison for approval by the 802.11 WG.
Regards,
Joseph Levy (InterDigital) IEEE 802.11 AANI SC Chair |