Mobile network testing blog

Stories & insights

Mobile network testing

Written by Johanna Sochos | March 1, 2018

Measuring QoE of mobile data applications: Behind the scenes (part 2)

In the previous post, we explained how to measure QoE of mobile data applications on smartphones by means of success rate and the duration of a series of actions. Based on large-scale real field data, we showed how the duration saturates at higher available network speeds. But where does saturation come from? And what is going on in the background, influencing the measurement results of mobile apps such as Facebook and Dropbox?

Measuring QoE of mobile data applications

The reasons for the measured saturation of app test durations can be found in the underlying phases of a file upload/download. As the illustration below reveals, the data transfer itself is only one part of the whole process. The other parts are essential for a real service and drive the customer experience.

However, the underlying file upload/download phases increase the test duration compared to plain HTTP transfers and are not usable for estimating the physical channel capacity.

Phases of a data upload/download to a third-party server
Phases of a data upload/download to a third-party server like Facebook or Dropbox
Lightbox öffnen
  • Transfers to Dropbox and Facebook are encrypted. Setting up an SSL session takes time since it requires several messages to be exchanged. In comparison, plain HTTP transfers without encryption to a self-hosted server without any upfront setup messages start immediately.
  • After the SSL session is initiated, the real data transfer takes place.
  • For uploads to Facebook and Dropbox, we see a large gap in the IP traffic where the upload is already complete but the client has not yet received confirmation of success. During this time span, the server is probably postprocessing the data, e.g. compressing pictures uploaded to Facebook to save storage space and allow faster downloads in the future. But also in the case of Dropbox where we don’t expect data compression since it is a cloud storage service, there is a certain time span dedicated to postprocessing, maybe for data storage optimization.
  • For downloads, time is needed to render and display the new content on the screen.
  • Finally, the confirmation of a successful upload is sent from the server to the client. This can be only one short IP packet, but it requires network connectivity.
For high network speeds, e.g. in good coverage LTE, the transfer phase itself can be very short with a duration close to zero seconds. In this case, the other phases are the dominant factors for test duration.

For changing test conditions, we see that the length of the other phases depends on many factors. These include the latency between client and server; server performance and load; device performance, and processing complexity of the transferred content.

What does the actual transfer phase in mobile data applications look like?

In the case of uploads to Facebook, we see an interesting behavior: Although the latencies are very similar, the throughput ramp-up takes much longer compared to plain HTTP transfer tests. A typical example looks like this:

Typical throughput ramp-up behavior for both plain HTTP and Facebook uploads
Typical throughput ramp-up behavior for both plain HTTP and Facebook uploads: The transfer to Facebook needs 6 seconds to reach a stable throughput level compared to only 1 to 2 seconds for plain HTTP.
Lightbox öffnen

The underlying reason is not clear. It might be some optimization strategy in place on the Facebook servers, maybe for congestion control or network resource-saving. However, the implication is very clear: Even when looking at only the transfer phase, the average throughput of a Facebook test cannot reach the average plain HTTP throughput.

Consequently, we need to look at the maximum throughput achieved during a test in order to learn something about the possible network limitations when using third-party services such as Facebook. And the transfer phase has to be long enough to reach the maximum possible throughput. This can only be achieved by using larger files for transfer.

The average throughput of a Facebook test cannot reach the average plain HTTP throughput.

We wanted to know whether Facebook and plain HTTP are at least comparable with respect to the maximum throughput reached during a transfer phase or if there might be further limitations introduced by the third-party service. We, therefore, conducted tests in Switzerland with larger file sizes for upload and received the following results:

Durations and maximum throughputs for smaller files
Durations (left) and maximum throughputs (right) of uploads to Facebook compared to plain HTTP for different file sizes: Durations saturate faster for smaller files and the maximum throughputs for smaller files cannot reach plain HTTP throughputs.
Lightbox öffnen

The test duration shown in the left graph behaves as expected. Saturation is reached at higher HTTP throughputs when larger files are transferred because the slow ramp-up time contributes less to the overall transfer time. In addition, the level of saturation is higher for larger files since the server also needs more time for postprocessing.

In the other graph, the maximum throughput reached during uploads to Facebook is plotted against the maximum plain HTTP throughput. Only for very large files can Facebook approach the maximum plain HTTP throughput. For files below 50 Mbyte, the time for reaching the end of the slow throughput ramp-up is obviously not always enough.

The similarity in the maximum throughputs for large files implies, though, that there is no further limitation of the transfer speed in the measured throughput range for Facebook.

Answers to QoE of mobile data applications

What does this mean for testing QoE? How should mobile data application tests be used in mobile network testing? What is a good strategy to combine information from technical tests with QoE results in network optimization?

Stay tuned and get the answers in the final post of this series, or read part 1 in the meantime.

Related stories

Measuring QoE of mobile data apps for network optimization (part 3)

Read more

Interactivity test: Concept and KPIs (part 2)

Read more

Network Performance Score: Templates for easy support in all products

Read more

Subscribe MNT blog

Sign up for our newsletter

Stay up to date and get stories and insights with our frequent mobile network testing newsletter.

Stories by category

Benchmarking & optimization

More information

Field services & interference hunting

More information

Innovations in mobile network testing

More information

Testing from RF to QoE

More information

Informationen anfordern

Haben Sie Fragen oder benötigen Sie weitere Informationen? Nutzen Sie hierzu einfach unser Kontaktformular und wir setzen uns umgehend mit Ihnen in Verbindung.

Marketing-Einverständniserklärung

Ihre Anfrage wurde erfolgreich versendet. Wir nehmen in Kürze Kontakt mit Ihnen auf.
An error is occurred, please try it again later.