Written by Jens Berger | January 26, 2023
This study looks at data latency in real field mobile networks. Recently, we discussed how distance to the server can impact latency and jitter, how changing conditions in mobile networks affect latency and how delay jitter differs between uplink and downlink.
Now, we will analyze in more detail how applied data rate and packet size influence latency. As with previous studies, all measurements were obtained in mobile networks. To avoid motion-induced overlay effects, the measurements were all conducted at a static location.
How latency was measured
To obtain realistic latency measurements, a typical data stream for real-time applications was emulated using the two-way active measurement protocol (TWAMP) in line with IETF RFC 5357. TWAMP is based on the user datagram protocol (UDP) applied for most real-time network communications. A state-of-the-art high-end smartphone was used as the client device and the reflecting server software was placed on a server at a local internet service provider.
Figure 1: Interactivity test
We defined 23 individual packet streams with different packet sizes and packet frequencies resulting in nine different data rates. With each of these streams, we transported hundreds or even thousands of UDP packets to a network server and back. The mobile client device was forced to use 4G radio technology to avoid additional biases from latency differences due to technology changes during the measurement series. The set of 23 streams was transported 60 times over the mobile network at a static location with excellent radio coverage for all networks under test.
Packet size and frequency
A data rate in a packet-switched network is not an analog parameter of a continuous bitstream; rather, it is defined by the number of bytes transported via individual packets of a given size and sending frequency. The data rate is just a kind of overlay parameter for the data transmitted in a given observation period.
For this study, we defined packet sizes – known as protocol data units (PDU) – of 100, 650 and 1400 bytes, so that the largest one fit into the typical maximum transmission unit (MTU) for a single IP packet. These packets were sent in a frequency to achieve the target data rate for the packet stream. The target data rates were set at between 45 kbit/s and 20 Mbit/s, and the necessary packet frequencies were adjusted to between 4 and 3000 packets per second.
Measurement results
The packet delay measurements typically showed two-way latencies of between 25 ms and slightly above 50 ms depending on the packet stream and network used.
For low data rates, small packets sent at higher frequency have a clear advantage in latency over larger packets sent less frequently. This advantage decreases moving towards medium data rates, where we see a strong latency increase for the small packets across all the networks. In contrast, medium-size and large packets result in higher latencies for low data rates but achieve a latency optimum at typical medium data rates.
Looking at this optimum range of ~2 to 5 Mbit/s, there is almost no difference in latency between the networks for medium and large packets. In our case, this optimum is a two-way latency in 4G of about 40 ms.
Larger packets show a visible difference in latency at low data rates, where transmission time correlates directly with packet size – the larger the packet, the longer the transmission time – and low packet frequency in those cases. For medium and large packets, this dependence on packet size and frequency is reduced with increasing data rates and packet frequencies. As data rates increase, packet frequency starts to affect latency – the higher the packet frequency, the higher the latency. However, the differences at the upper boundary of tested data rates are much less pronounced than those at lower data rates.
It is worth noting that with the chosen setup and networks, it was not possible to obtain reliable results for packet frequencies higher than ~2500 packets per second, or >3 Mbit/s for 100 byte packets and >15 Mbit/s for 650 byte packets.
Discussion and consequences
These results underline once again that in order to obtain realistic data latency values for a given service or application, the measurement data stream has to have similar characteristics to the data stream of that application. There might be significant differences when using smaller packet sizes and/or lower packet frequencies.
If using ping or other methods like the TCP handshake for latency measurements, where only small packets are transmitted at a low frequency, the obtained latencies can be significantly different from actual latency values in a real application transmitting at a higher data rate.
The network and its scheduling mechanisms react dynamically to the requested transport capacity. This results in more or less different transport times under different load conditions, where differences manifest mainly for low data transport rates. Here, the differences between networks and individual packet characteristics are the greatest. For medium rates, the transport times are usually shorter and less dependent on stream characteristics.
Realistic and accurate latency measurements are required to evaluate network performance for real-time and interactive applications, where latency plays a key role in quality of service. For latency measurements, we therefore recommend applying packet stream characteristics such as packet size and frequency, data rates and transport protocols typically used for those real-time or interactive applications. R&S MNT supports many pre-defined load patterns, emulating typical bit rates and packet characteristics of real applications and use cases.
Evolving 5G radio technology will enable significantly shorter transport times than 4G or even HSPA. Apart from realistic and accurate results, the measurement approach and equipment has to be precise enough to discriminate accurately between ever smaller absolute differences in latency. The implementation used on the R&S MNT QualiPoc in this study has been proven for a statistical resolution of accuracy of a few microseconds on a consumer Android smartphone.
Read more about interactivity test in part 1 - 8 of this series and download our white paper "Interactivity Test"
Interactivity test: QoS/QoE measurements in 5G (part 1)
Interactivity test: Concept and KPIs (part 2)
Interactivity test: Examples from real 5G networks (part 3)
Interactivity test: Distance to server impact on latency and jitter (part 4)
Interactivity test: Impact of changing network conditions on latency and jitter (part 5)
Interactivity test: Packet delay variation and packet loss (part 6)
