Fine-grained Latency Analyzers¶

An Overview of LTE Network Latency¶

Data transmission in the mobile networks takes a scheduling-based approach. The serving base station schedules radio resources based on the mobile device’s demand, radio qualities, and congestions. In LTE and 5G, data transmission mainly involves the physical-layer and link-layer protocols, including medium access control (MAC [2,3]), radio link control (RLC [4,5]), and packet data convergence protocols (PDCP). The data transmission mechanisms differ between uplink and downlink [1].

Uplink: The uplink data transmission is from the mobile device to the base station. It is requested by the device and granted by the base station. As shown in the simplified figure below, the device exchanges signaling messages with the base station to request for UL grants (radio resources scheduled for the device). The signaling messages include the scheduling request, buffer status report, grant messages, and acknowledgement [2,3]. The device can then use the grant to send uplink data. We call this waiting period as waiting ltency. If the packet is large, it will need multiple grants from the base station to be completely sent out. The latency from a packet’s first bit being sent out to its last bit being sent out is defined as transmission latency. If the base station cannot decode some data, it will send a negative ACK to the device, which re-sends the data. This uplink packet thus experiences retransmission latency before it is fully received by the base station.

Downlink: The downlink data transmission is from the base station to the device. It is simpler than the uplink data transmission, since the base station knows how much data to transmit. To this end, the base station can directly allocate radio resource without client-side buffer status report. If the transmission from the base to the device fails, the MAC layer will attempt a retransmission. When the MAC retransmission is not sufficient (due to too excessive retransmission failure, for example), RLC layer kicks in for retransmission.

Latency analyzer Overview¶

MobileInsight provides a breakdown analysis of the LTE data plane packets latency into multiple components. It focuses on the access network latency: the latency of packets between a device and a base station. This is achieved by processing and analyzing messages from multiple layers: PDCP, RLC, MAC, and PHY layers.

MobileInsight has provide 2 latency analyzers: lte_dl_retx_analyzer and uplink_latency_analyzer. As shown in the overview section, the following components are available:

• Downlink (lte_dl_retx_analyzer):

  • MAC retransmission latency

  • RLC retransmission latency

• Uplink (uplink_latency_analyzer):

  • Waiting ltency

  • Transmission latency

  • Retransmission latency

Using the analyzers¶

The following examples show how to use the analyzers. (both available in mobileinsight-core/examples)

We take mobileinsight-core/examples/dl_retx_analyzer_test.py to show how to get downlink latency statistics from offline logs.

First, define an object of OfflineReplayer to load logs from a .mi2log file.

src = OfflineReplayer()
src.set_input_path(sys.argv[1])

Then, define an object of LteDlRetxAnalyzer and bind it to src.

lteAnalyzer = LteDlRetxAnalyzer()
    lteAnalyzer.set_source(src)

Run the offline replayer to do analytics.

src.run()

After analysis is finished, retransmission delays are classified by bearer index and stored in lteAnalyzer.bearer_entity. Take bearer 1 as an example, lteAnalyzer.bearer_entity[1].mac_retx and lteAnalyzer.bear_entity[1].rlc_retx store all samples of MAC retransmission delays and RLC retransmission delays, respectively. Here is an example about how to compute average retransmission delay for both layers.

mac_delay = 0.0
mac_delay_sample = 0
rlc_delay = 0.0
rlc_delay_sample = 0

for _, bearer in lteAnalyzer.bearer_entity.items():
    for item in bearer.mac_retx:
        mac_delay += item['mac_retx']
        mac_delay_sample += len(bearer.mac_retx)

    for item in bearer.rlc_retx:
        rlc_delay += item['rlc_retx']
        rlc_delay_sample += len(bearer.rlc_retx)

avg_mac_delay = float(mac_delay) / mac_delay_sample if mac_delay_sample > 0 else 0.0
avg_rlc_delay = float(rlc_delay) / rlc_delay_sample if rlc_delay_sample > 0 else 0.0

If we run mobileinsight-core/examples/dl_retx_analyzer_test.py, it will print out results in the following format:

The example for uplink latency (mobileinsight-core/examples/offline-latency-analysis-ul.py) loads a log file and then prints out the average latency for each uplink latency component.

Similar to downlink latency analyzer, we first define an offline replayer and an uplink latency analyzer to get analysis results.

src = OfflineReplayer()
src.set_input_path(sys.argv[1])

analyzer = UplinkLatencyAnalyzer()
analyzer.set_source(src)

src.run()

stats = analyzer

The analyzer will take the specified file as input. It reads the MAC buffer and PHY signaling messages to break down latency into components. The latency componets are all accessible in all_packets in the analyzer return. Then we can fetch the components in it and compute the average of total delay, waiting delay, transmission delay and retransmission delay as follows:

# For each delay component, compute the sum of delays
total_retx = 8 * stats.cum_err_block[0]
for latency in stats.all_packets:
  total_wait += latency['Waiting Latency']
  total_trans += latency['Tx Latency']
  total_retx += latency['Retx Latency']
# Compute the sum of overall delays
total_latency = total_wait + total_trans + total_retx
n = len(stats.all_packets)

# Compute the average of each delay component, and overall delay
print ("Average latency is:", float(total_latency) / n)
print ("Average waiting latency is:", float(total_wait) / n)
print ("Average tx latency is:", float(total_trans) / n)
print ("Average retx latency is:", float(total_retx) / n)

If we run the script above, it will dump the break-down of uplink latency for each packet and in average.

Reference¶

[1] Supporting Mobile VR in LTE Networks: How Close Are We?, ACM SIGMETRICS 2018

[2] 3GPP TS36.321: Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification

[3] 3GPP TS38.321: 5G NR; Medium Access Control (MAC) protocol specification

[4] 3GPP TS36.322: Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification

[5] 3GPP TS38.322: 5G NR; Radio Link Control (RLC) protocol specification

[6] 3GPP TS36.323: Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification

[7] 3GPP TS38.323: 5G NR; Packet Data Convergence Protocol (PDCP) specification