Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-AANI] 11-16/1151r1 - updated Draft Reply to Liaison from 3GPP RAN2 on Estimated Throughput 11-16-1384

Hi Thomas,


Thanks for your comments. See my reply inline as well.






From: Thomas Derham [mailto:thomas.derham@xxxxxxxxxxx]
Sent: Wednesday, November 09, 2016 5:31 PM
To: George Calcev <George.Calcev@xxxxxxxxxx>; STDS-802-11-AANI@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-AANI] 11-16/1151r1 - updated Draft Reply to Liaison from 3GPP RAN2 on Estimated Throughput 11-16-1384


Hi George


Thanks for sharing your thoughts and the good discussion. Some follow up comments inline below:


From: George Calcev [mailto:George.Calcev@xxxxxxxxxx]
Sent: Wednesday, November 09, 2016 3:16 PM
To: Thomas Derham <thomas.derham@xxxxxxxxxxx>; STDS-802-11-AANI@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-AANI] 11-16/1151r1 - updated Draft Reply to Liaison from 3GPP RAN2 on Estimated Throughput 11-16-1384


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.


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.


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.


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.








Best regards,







From: Thomas Derham [mailto:thomas.derham@xxxxxxxxxxx]
Sent: Wednesday, November 09, 2016 3:53 PM
To: STDS-802-11-AANI@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-AANI] 11-16/1151r1 - updated Draft Reply to Liaison from 3GPP RAN2 on Estimated Throughput 11-16-1384


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>
Sent: 09 November 2016 09:45
To: STDS-802-11-AANI@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-AANI] 11-16/1151r1 - updated Draft Reply to Liaison from 3GPP RAN2 on Estimated Throughput 11-16-1384


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








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:


From: Levy, Joseph S [mailto:Joseph.Levy@xxxxxxxxxxxxxxxx]
Sent: 9 November 2016 04:08
To: STDS-802-11-AANI@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-AANI] 11-16/1151r1 - updated Draft Reply to Liaison from 3GPP RAN2 on Estimated Throughput 11-16-1384


An updated Draft Reply to Liaison from 3GPP RAN2 on Estimated Throughput (11-16-1384) is available:


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. 



Joseph Levy (InterDigital)

IEEE 802.11 AANI SC Chair