Re: [Marnew] RFC 6077

Of course, all transport data in a mobile network is ephemeral ... aggregate channel BW, per user BW, latency, ...  on time scales of 10-100's of ms and variations on the order of 50:1 or more (or less).  It would be good to get some information particularly if you also knew the range of accuracy.  But RAN vendors have been loath to expose this since its hard to predict accuracy and easy to make bad decisions based on ever changing data.   However, on a larger time scale (say many seconds / minutes), you can conclude some level of overall aggregate channel conditions.  Each specific user still may see a wide variation of performance since they may be in very good signal-to-noise areas (getting a higher share of BW) or very bad signal-to-noise areas (getting a very low BW).  But in aggregate, you can conclude that there are problems and some mitigation of traffic for certain classes of users could result in an aggregate improvement in QoE.   An operator will argue that they can conclude this based on data and heuristics they can get.  An ability to expose this  to clients/apps would seem to be highly advantageous (think SPUD maybe). And of course, some new structures/protocols to be able to expose/act on this information would be needed. Fundamentally, it would be nice to divorce traffic management methods, ... from the dependence on traffic type detection mechanisms.

              Tom

From: Marnew [mailto:marnew-bounces@iab.org] On Behalf Of Blake Matheny
Sent: Thursday, September 24, 2015 8:55 AM
To: Andreas Terzis
Cc: Vijay Devarapalli; Ca By; Smith, Kevin, (R&D) Vodafone Group; Scharf, Michael (Michael); marnew@iab.org
Subject: Re: [Marnew] RFC 6077

People have been calculating bandwidth on their own successfully for a long time, I’ll look at the code and see what my be different here.

At the risk of taking this far off track, maybe this would be a good lunch time discussion. Bandwidth is necessary, but not sufficient, for fully understanding underlying network characteristics.

-Blake

From: Andreas Terzis
Date: Thursday, September 24, 2015 at 9:48 AM
To: Blake Matheny
Cc: Vijay Devarapalli, Ca By, "Scharf, Michael (Michael)", "Smith, Kevin, (R&D) Vodafone Group", "marnew@iab.org<mailto:marnew@iab.org>"
Subject: Re: [Marnew] RFC 6077

Blake,

Please look at requestBandwidthUpdate() coming up in Android M as an API of exposing available capacity on the radio downlink.

http://developer.android.com/reference/android/net/ConnectivityManager.html#requestBandwidthUpdate(android.net.Network)<https://urldefense.proofpoint.com/v1/url?u=http://developer.android.com/reference/android/net/ConnectivityManager.html%23requestBandwidthUpdate%28android.net.Network%29&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=N5wveO%2BsGGBYBYSvInKvypoNwi%2BY2hKoEtcFsEA%2Fks8%3D%0A&s=21eef043e08976b201cd0e05881e7499bf3c38a77ed5f120869e9941740c3a6a>

Andreas

On Thu, Sep 24, 2015 at 10:38 AM, Blake Matheny <bmatheny@fb.com<mailto:bmatheny@fb.com>> wrote:
No Operator would share that kind of information from their base station. That is a non-starter. The base stations are busy with what they usually do best - delivering as many bits as possible to the UEs attached to it.

Vijay

I’ve had discussions with carriers that would contradict that statement.

_______________________________________________
Marnew mailing list
Marnew@iab.org<mailto:Marnew@iab.org>
https://www.iab.org/mailman/listinfo/marnew<https://urldefense.proofpoint.com/v1/url?u=https://www.iab.org/mailman/listinfo/marnew&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=N5wveO%2BsGGBYBYSvInKvypoNwi%2BY2hKoEtcFsEA%2Fks8%3D%0A&s=3fd4cb16c45aa04137335dfdb0f66a36c70cfdb5cb04db07d7cf7b3e78acb149>