In mobile network speed measurement, the most overlooked component is not the measuring device but the server on the other end. When a drive test team downloads and uploads files in the field over several operators' SIMs, it is measuring two things at once: the operator's radio performance, and the capacity of the path to your test server. If the server side is undersized, the campaign stops measuring the operator and starts measuring your own infrastructure — and the resulting report becomes indefensible, whoever you present it to. This guide covers how these measurement campaigns work and what an FTP/test server must provide to support them.
Operator coverage and service quality are not tracked by estimation; they are tracked with data measured in the field. The practice is known as drive testing and benchmarking. A measurement team follows defined routes, starts data transfers over each operator's connection, and records results together with GPS coordinates.
We covered the methodology and reporting side of FTP-based throughput measurement in detail in our guide on FTP-based throughput testing and QoS reporting on 5G networks.
The main indicators collected are:
Who commissions this work? Three parties: operators themselves (to benchmark their own network and competitors'), the regulator (to verify compliance), and independent measurement companies (to produce impartial comparison reports). If your work falls into the third group, the report has to be technically unchallengeable.
Mobile service quality in Turkey is regulated by the Information Technologies and Communications Authority (BTK). Under the electronic communications service quality regulation and its associated notices, operators must produce two kinds of data:
The BTK also runs independent field tests with its own measurement vehicles and verifies the figures operators report. Where targets are not met, administrative sanctions follow.
The implication matters: measurement data is not merely a technical output but a document that can trigger enforcement. Every link in the measurement chain — the server as much as the field device — has to be defensible.
A throughput test is simple in principle: the device downloads a file from, or uploads a file to, the server; speed is derived from elapsed time and bytes transferred. But that measurement reflects the narrowest point on the path.
If the operator can deliver 400 Mbps at that spot while your server caps out at 200 Mbps, your report says 200 Mbps. What you measured is no longer the operator's performance but your server's ceiling. This failure is silent: nothing warns you, all results simply come out systematically low.
Hence the core design rule for a measurement server: it must be decisively faster than the network under test, under all conditions. The headroom on the server side should be several times the peak a single device can reach on 5G — because multiple devices test simultaneously in the field.
In ETSI's technical specifications for QoS measurement in mobile networks, servers used for data tests are grouped by how much control the tester has over them:
Most commercial measurement and reporting work runs on class B servers: under your control, of known capacity, reachable over the public internet. The critical point — which the standard itself stresses — is that measures must be in place to stop third-party traffic from influencing the result. In practice: the server must be yours, and it must be doing nothing else during the campaign.
Port capacity must be explicit and not shared. Phrasing like "up to 1 Gbps" is not good enough for measurement work; capacity has to be guaranteed and free of other tenants during the campaign. You should be able to state "the server side was guaranteed at X Gbps" in your report. On what Gbps figures do and do not mean, see our explainer on capacity figures.
If you are comparing several operators, all of them must reach your server at comparable quality. If one operator's traffic arrives over a direct path while another's takes a long transit route, the difference you measure is routing, not radio performance. Infrastructure located in-country with multi-operator peering removes that risk.
Server location translates directly into latency. If you measure networks in Turkey, the server belongs in Turkey; an overseas server adds tens of milliseconds of fixed delay, and with TCP-based transfers that feeds straight into measured throughput.
Field teams do not work with a single handset. Several operators, multiple devices and often parallel sessions run at once. The server must absorb those concurrent connections without hitting a CPU or disk I/O wall — which is why serving test files from memory or NVMe storage matters.
Upload testing is frequently neglected. Yet in an upload test the bottleneck is the server's receiving capacity. The port must be symmetric, with no write-side throttling.
Operators widely use IPv6 and NAT64 on the mobile side. If your server is IPv4-only, some tests take unexpected paths or fail outright. Dual stack should be the default.
FTP is the classic method and still common in reporting, but modern campaigns also need HTTP/HTTPS downloads, iperf3 and UDP-based tests. The server must host these services together with the required ports open.
Other workloads running concurrently — backups, scans, updates — corrupt the result. A measurement server should be single-purpose, with maintenance scheduled outside campaign windows. Before putting a new node into service, we suggest working through our guide on the first 10 steps to secure your server.
This work does not call for a standard web server but for a node of known capacity, dedicated solely to you. Nubitro's offering for the telecommunications and ISP segment is built for exactly this: dedicated physical servers with unshared hardware, high bandwidth and multi-operator network connectivity. Teams wanting a more flexible starting point can also look at our high-performance VDS options located in Turkey.
If you need a measurement node, a speedtest server, peering connectivity or campaign-specific capacity, talk to our team — we plan the build and the capacity around what the campaign actually requires.
Both are used. FTP remains common because it has long been treated as the reporting standard; HTTP/HTTPS sits closer to real user experience. The soundest approach is to measure both and report them separately.
Large enough to run for at least 10-15 seconds at the speed being measured. On a network where you expect 500 Mbps, a 10 MB file finishes in under a second and the test ends before TCP has ramped up. Keeping the file size constant across the campaign matters for comparability.
The rule of thumb: at least two to three times the combined peak of all devices testing simultaneously. Since a single device can reach several hundred Mbps on 5G, 1 Gbps can fall short for a team running multiple handsets. Plan capacity against campaign size.
For small, single-operator work, a VDS with guaranteed resources can do the job. But in multi-operator comparison reports it matters that you can document capacity was not shared — and there a physical server is the more defensible choice.
If you are measuring networks in Turkey, yes. An overseas server introduces fixed delay from international transit, which depresses TCP performance and can mask the differences between operators.
Yes, provided the campaign windows do not overlap. Two simultaneous measurements corrupt each other's results. Where campaigns do overlap, use separate nodes or size capacity accordingly.
Turkey (Türkçe)
Worldwide (English)
