Táto webová stránka využíva súbory cookies. Pomáhajú nám zlepšovať kvalitu stránky, pokračovaním v prehliadaní súhlasíte s ich použitím.

Methodology

The test delivers an accurate measurement of the maximum bandwidth available over a given Internet connection. This is achieved by transferring multiple parallel data streams over separate TCP connections within a predefined amount of time. The transferred data consist of randomly generated data with high entropy. It is not expected that the (pseudo) random number generator meets cryptographic requirements. However, it must effectively prohibit data compression during the transmission.

In order to increase the probability that the test can be performed even within networks protected by firewalls and proxy servers, the data is transferred over a TLS connection (possibly using the TLS Record Protocol without encryption).



System Components

Test Environment for Mobile Apps and Java Test:


Test Environment for WebSocket Test

By default, data is transferred between client and server over the TCP port 443 in order to avoid interference with firewalls as much as possible. The ports for communication and data transfers between the different servers themselves are configurable. 

In general, the format of the transferred data is JSON. Only the Test Server uses a different protocol to keep the communication simple and therefore the workload of the server at a minimum.

Global Constants

The following constants are used throughout the specification:

 

n  number of parallel TCP connections (1 ≤ n ≤ 10); default: n = 3

s   initial size of data block sent during the test; default: s = 4.096 Bytes

d  duration of pre-test; default: d = 2 s

t   duration of test; default: t = 7 s

p  number of “pings” during latency test (i.e. measurement of time elapsed between sending a data packet and receiving the reception response); default: p = 10

c   number of received chunks after which the Test Server sends statistical data to the client when processing the Upload Test;  default: c = 10

Test Procedure 

This section is not intended as specification but as overview.

The test follows the procedure outlined below. The test consists of seven phases, which are carried out one after each other, i.e., phase m starts after phase m – 1 has finished. That means that the phases do not overlap.


Phase 1: Initialization

The Test Client tries to connect to the Control Server on the TCP port 443 using TLS. In order to pass through certain firewalls - which might block unencrypted data transmissions - this might be necessary. The data streams themselves are optionally unencrypted. In order for the computational cost of encryption not to deteriorate the measurement results, encryption and authentication parameters should be chosen as low as possible, e.g., TLSv1 (SSL_RSA_WITH_RC4_128_MD5).

The server authentication key has a short length in order to reduce delays due to the TLS handshake. TLS-security is not an objective.

After establishing a proper connection, client and server exchange the information, which is required for running the test.

The client sends its version number, geo-location data and IP address as well as other relevant information to the Control Server.

The Control Server determines the Test Server to be used. It then generates a token consisting of the following components:

  • a unique test ID (UUID)
  • the time at which the measurement is allowed to start (a string representing Unix time)
  • the period of time during which access to the Test Server is allowed (a string representing number of seconds)
  • the maximum number of permitted parallel connections from the client to the server (a string representing a positive integer)
  • the Base64-encoded HMAC-SHA-1 value [1] of the string composed of the components mentioned above, where the components are separated by space characters. The HMAC value is computed using a key, which should only be known to the Test Servers

The Control Server then transmits the token as well as all the additional test parameters (IP address of the Test  Server, public IP address of the client, number of parallel TCP connections, … ) to the client. The token is used for identifying the test session.


Phase 2: Downlink pre-Test

In Phase 2, the client opens n TCP connections to the assigned Test Server. Within each TCP connection, the client requests and the server sends a data block of size s (randomly generated data with high entropy). 

While the duration of the pre-test has not exceeded d, the client requests a data block of double size compared to the last iteration step. The transfer of the last data block will be finished even if the duration has already exceeded d

At the end of the pre-test, all TCP connections are left open for further use if more than four chunks have been transmitted in the downlink pre-test. Otherwise, n is reduced to 1.


Phase 3: Latency Test

During this phase, the client sends p “pings” in short intervals to the Test Server to test the latency of the connection. One “ping” consists of the transmission of short strings via one of the TCP connections to the Server, which returns short strings as acknowledgement. 

The client measures the time between sending and receiving the return message, while the server additionally measures the time between sending its return message and the client’s reception response. 

The client stores all measurements, and the median of all measurements is used as result since the test should provide an approximated lower bound as latency.


Phase 4: Downlink Test

Within each of the n TCP connections opened during phase 2, the client simultaneously requests and the server continuously sends data streams consisting of fixed-size chunks of size s (randomly generated data with high entropy).

All transmissions start at the same time, which is denoted as relative time (t) 0. For each TCP connection k, 1≤kn, the client records the relative time tk(j)  and the amount sk(j) of data received from time 0 to tk(j)  for successive values of jj≥1 (usually after receiving each chunk). After time t, each TCP connection is reset immediately after the next transmitted chunk has been received. For each k, 1≤kn, let mk be the number of pairs (sk(j)tk(j)) which have been recorded for TCP connection k. Then

Let  Then the amount sk of data received over TCP connection k from time 0 to time t* is approximately

and the data rate R for all TCP connections together is

This value is taken as an approximation of the download capacity.


Phase 5: Uplink pre-Test

In Phase 5, the client opens n TCP connections to the assigned Test Server again. Within each TCP connection, the client sends a data block of size s(randomly  generated data with high entropy). 

While the duration of the pre-test has not exceeded d, the client sends a data block of double size compared to the last iteration step. The transfer of the last data block will be finished even if the duration has already exceeded d. At the end of the pre-Test, the TCP connections are left open for further use.


Phase 6: Uplink Test

Within each of the n TCP connections opened during phase 5, the client continuously sends data streams consisting of fixed-size chunks of size s (randomly generated data with high entropy). All transmissions start at the same time, which is denoted as relative time 0. 

For each TCP connection k, 1≤kn, the server gives feedback to the client by sending the relative time tk(j) and the amount sk(j) of data received from time 0 to tk(j) for successive values jj≥1

   (a) after receiving each chunk whose transmission has taken more than 1 ms or 

   (b) 1 ms after the previous feedback otherwise.

After time t, it is tested at intervals of .25 s whether all feedbacks for chunks sent from the client to the server until time t – 1 s have been received. As soon as this is the case, all TCP connections are reset. Otherwise, the test is aborted after time t + 3 s. 

For each k, 1≤kn, let mk be the number of pairs (sk(j)tk(j)), which have been recorded for TCP connection k. Then

Let  Then the amount sk of data received over TCP connection k from time t=0 to time t* is approximately

and the data rate R for all TCP connections together is

This value is taken as an approximation of the upload capacity.


Phase 7: Finalization

After finishing all tests, the client sends the collected data to the Control Server. All results and additional information on the client are transferred directly to the Control Server. 

Both datasets are then compared by the Control Server to check the quality and integrity of the result. The Data Server stores all tests, successful or unsuccessful.

Network quality test (Network neutrality test or QoS test)

Based on the recommendation of the BEREC the network quality test measures some parameters which have a decisive influence on the quality of the internet access. The network quality test will be carried out directly after the upload test and consists of 6 test groups. Individual tests of the test groups and the individual test groups themselves may be performed in parallel or behind one another.

The following test groups are implemented in the network quality test:

(a)   Website download & rendering

The device will download one or more defined web pages and build these web pages in a background browser. The process monitors the size of the website in kilobytes, the HTTP response code from the server, the header data of the response and the times of the download and the rendering of the page. The NetTest enables configuration of the URL of the web page and an optional timeout.

(b)   HTTP-proxy (transparent proxy)

The network neutrality test server provides download data and maintains a hash value. The client downloads the data and also calculates the hash value. The control server compares the two hashes. When they are different the data has been modified by a proxy during the download. The NetTest enables configuration of the URL of the download data and an optional timeout.

(c)   Non-transparent proxy

The client sends a random incorrect, falsified or incomplete HTTP request (e.g. „GET /“ or „GET / HTTR 8.7“) to the network quality test server. This server behaves like an echo service and responds with the same incorrect HTTP header. The control server compares the transmitted and received header data. If they are not identical then a non-transparent proxy has changed the faulty HTTP request. Normally such proxies do complete the faulty request or remove an incorrect request completely. The NetTest enables configuration of the URL to which the request is sent, the port from which the request is sent and the distorted or incomplete request which may be used.

(d)   DNS

The client sends a DNS query with optional specified resolver (e.g. 8.8.8.8). In the evaluation the response from the resolver that was automatically assigned to the client by the ISP will be compared with the known and correct results or with results of other resolvers. In addition it is checked if the operator allows third-party resolver. The NetTest enables configuration of the test domain and an optional particular resolver.

(e)   TCP and UDP

The client sends TCP or UDP packets to the specified port and waits for a reply. The network quality test server receives these packets and responds to them. The control server compares the transmitted and received packets. It measures whether (TCP-/UDP-) packets have arrived or were blocked, how many packets (UDP) have arrived or how many packets had to be resent (UDP).  Also the variance of the package (UDP) can be calculated. The NetTest enables configuration of the port and the number of packets to be sent.

(f)    VoIP

The client sends n UDP packets over defined VoIP-ports using a defined time interval. The server receives these packets, measures the time delays between them and calculates any divergence from the default delay. The NetTest enables configuration of port numbers, amount of packets and default delay.

(g)   Traceroute

The client sends UDP packets with defined amount of allowed hops to the server and receives back the answer of the last hopping interface to calculate the maximum amount of hops to the server. The NetTest enables configuration of timeout, target URL and maximum amount of allowed hops.

Project coordinator:

CZ.NIC, z.s.p.o.
Milesovska 1136/5,
130 00 Praha 3, CZ

Tel.: +420 770 125 720
Email: michala.radotinska@nic.cz