QueueTrack: Framework for Detecting the Onset of Queueing in Mobile Networks

QueueTrack: Framework for Detecting the Onset of Queueing in Mobile Networks Hamid Hassani, Anudeep Karnam, Kishor Joshi, Sonia M. Heemstra, Ignas G. Niemegeers, George Exarchakos Eindhoven University of Technology, The Netherlands

arXiv:2611.02038v1 [cs.NI] 1 Nov 2026

{h.hassani,s.s.a.karnam,k.c.joshi,sheemstradegroot,i.g.m.niemegeers,g.exarchakos}@tue.nl

Abstract—In mobile networks, timely and accurate detection of the onset of queueing at path bottlenecks remains challenging for end-to-end congestion control algorithms (CCAs), where end hosts have limited visibility into queue status. Traditional congestion signals, such as packet loss, round-trip time (RTT), and one-way delay (OWD), have well-known limitations for early queue buildup detection. This paper presents QueueTrack, a practical end-host framework to detect the onset of queueing in mobile networks. QueueTrack computes a queue buildup indicator, denoted QBI, from endpoint-observable packet-level timing statistics, without requiring tight synchronization between end hosts or modifications to the existing network infrastructure. We develop and assess the complete QueueTrack machine learning (ML) pipeline, including data collection, labeling, model training, and testing, on a 5G testbed built on the OpenAirInterface platform, under a range of scenarios with competing TCP traffic. The experimental results show that QueueTrack can reliably detect the onset of queueing at the 5G base station using lowcomplexity classification models such as logistic regression. For example, QueueTrack achieves an F1 score of approximately 80% in a challenging mixed TCP/UDP scenario. These findings confirm that QueueTrack can serve as a practical framework for developing CCAs that target low delay, as well as for network telemetry and network monitoring in mobile networks. Index Terms—Mobile networks, queue buildup indicator, congestion signal, low latency, OpenAirInterface testbed

I. I NTRODUCTION Emerging time-critical applications such as extended reality, teleoperation, and cloud gaming demand both high data rate and low latency communication. For such immersive services, data rate may need to range from 100Gbps to 1Tbps, with latency below 1ms [1]. However, these requirements cannot be fully met by current 5G networks [1], [2], [3], and many network capabilities are expected to grow substantially over the next decade to support emerging data-intensive applications [4], [5]. While 3GPP and IEEE 802.11 standardization activities have primarily focused on physical and link layers, recent studies highlight the importance of transport-layer protocols, particularly congestion control algorithms (CCAs), in enabling real-time applications [6], [7]. The need for major upgrades to current CCAs is also reflected in initiatives such as Google BBR [8] and L4S [9]. The choice of an appropriate congestion signal1 is a key challenge to CCA design, since the signal should detect the onset of queueing at the path bottleneck before excessive 1 An indicator used by CCAs to detect congestion within the network.

queueing delay for effective rate adaptation. Existing CCAs primarily rely on packet loss or delay measurements as congestion signals. However, these signals may prove insufficient for next-generation applications that require both high data rate and low latency [10]. Packet loss is not ideal for low delay operation since it typically triggers rate reduction only after queue overflow has occurred, leading to high queueing delay (QD) [11]. Moreover, CCAs that rely on packet loss as the congestion signal, such as TCP Cubic [12], are unable to distinguish whether packet loss is caused by queue overflow or by wireless impairments such as degraded channel conditions, interference, or handovers. The use of packet delay as a congestion signal in CCAs such as TCP BBR [8] can be inaccurate for inferring queue buildup at the path bottleneck. For instance, round-trip time (RTT) is known to be inaccurate when there is queueing in the reverse path, i.e., asymmetric forward and reverse path conditions [13]. One-way delay (OWD) provides a more direct forward-path measurement, but it is challenging to measure robustly due to, e.g., clock offset and skew between the sender and receiver [6]. There are also alternative approaches for mobile networks, such as decoding radio-control information using networkwide sniffing [14], [7], [15], [16] to estimate available capacity, or using explicit congestion notification (ECN) protocols [17] at bottleneck queues. However, these strategies are often impractical due to deployment and upgrade difficulties. For example, L4S [9], which relies on ECN feedback from the base station (BS), requires extensive updates to network infrastructure and end-user devices, making widespread adoption challenging. To address the above challenges, we present QueueTrack, a deployable end-host framework that exposes implicit information about queue states using packet timing statistics, without requiring access to the queue status at the BS. Instead of relying on packet loss, RTT, or OWD to detect queue buildup at the BS, we propose a novel metric, the queue buildup indicator (QBI). Using measurements at the user equipment (UE), QBI provides a practical signal for identifying the onset of queueing at the path bottleneck. Note that, in a 5G edge architecture, the bottleneck queue typically lies at the radio link control (RLC) layer of the BS [18]. QueueTrack uses simple machine learning (ML) models, i.e., logistic regression (LR), support vector machine (SVM), and multilayer perceptron (MLP), to avoid unnecessary CPU overhead. Furthermore,

it does not require any modifications to the existing network infrastructure and can be integrated with low-delay CCAs or used for network telemetry, runtime diagnostics, and network monitoring. The main contributions of this paper are as follows: • We introduce QBI, a novel metric for tracking the queue status at the RLC layer of the BS in 5G edge networks where the air interface is the path bottleneck. QBI is computed from packet-level timing statistics observed at the end hosts and does not require tight synchronization between end hosts. • We develop QueueTrack, a user-space end-host software framework that uses QBI and ML models to detect the onset of queueing at the BS. QueueTrack is flexible and easy to deploy, without requiring changes to the existing network infrastructure. • We conduct an extensive measurement campaign to build a dataset and evaluate QueueTrack on a 5G testbed using the OpenAirInterface (OAI) platform [19] and under a broad range of scenarios, including single- and multi-UE settings, coexistence with widely used CCAs, robustness to uplink feedback loss, and measurement perturbations. • The experimental results demonstrate that QueueTrack can accurately detect the onset of queueing under realistic and complex 5G testbed conditions. Moreover, the evaluated learning models, i.e., LR, SVM, and MLP, generalize to previously unseen mixed-flow scenarios with TCP Cubic and BBR cross-traffic, achieving F1 scores of 80%. The remainder of the paper is organized as follows. In Section II, we review the related work. We present the system architecture of QueueTrack in Section III, and in Section IV, we introduce the QBI metric. In Section V, we describe the testbed, measurement process, and dataset construction. Next, we present the QueueTrack learning pipeline in Section VI. In Section VII, we discuss the performance evaluation results. We conclude the paper in Section VIII. II. R ELATED W ORK The primary objective of CCAs is to estimate the available bandwidth and adjust the send rate, e.g., by updating the TCP congestion window (CWND) size. To this end, the literature has proposed several congestion signals, which are generally divided into loss- and delay-based approaches. Loss-based CCAs, such as TCP BIC [20] and TCP Cubic [12], use packet loss as the congestion signal, whereas delay-based CCAs, such as TCP BBR [8] and TCP Copa [21], rely on delay measurements, e.g., RTT, to infer queue buildup at the path bottleneck. ECN protocols, such as L4S [9], use queue dynamics, e.g., queueing delay, as an explicit congestion signal. While such mechanisms can provide timely congestion feedback, they require changes in existing network equipment. This often implies widespread software upgrades across network nodes, such as access points and BSs. This process is notably expensive and resource-intensive, which can ultimately restrict the agile integration of innovative solutions.

There are alternative approaches that rely on network-wide sniffing to measure wireless channel bandwidth, as outlined in [14], [7] for LTE and [15], [16] for 5G. They deploy passive sniffers in different locations to capture and decode the control channel over the air interface. However, decoding control channels is not a practical solution [22], and such approaches may suffer from performance limitations under realistic network conditions. [23] presents a tool called CLAW that can estimate the LTE cell-wide resource utilization based on the physical layer information, such as reference signal received quality (RSRQ), available on unmodified commodity (but rooted) mobile handsets. CLAW needs around one RTT to estimate the available bandwidth. However, results in [23] show that the predictive power of signal strength is relatively limited [14]. Furthermore, energy measurements have typically resulted in significant estimation errors due to interference [7]. ExLL [24] analyzes the patterns in packet reception in short time windows, i.e., at an LTE subframe granularity, to infer the LTE link bandwidth. This solution relies on end-to-end statistics, so it is sensitive to network dynamics and may inaccurately estimate the available bandwidth [14]. Cesar [25] is another advanced delay-based CCA for cellular networks, designed to maintain low delay and high data rate by reducing the impact of non-congestive delays, such as scheduling and processing delays at the BS. While Cesar has been evaluated in commercial LTE and 5G networks, the authors in [25] focus primarily on performance comparisons with other CCAs and do not report detailed resource-utilization behavior. Therefore, as with other delay-based approaches, resource-utilization concerns remain for Cesar. Biscay [26] is a recently proposed CCA for mobile networks. It relies on fine-grained radio indicators extracted from the device chipset to estimate the available bandwidth, and then combines this estimate with RTT to adjust the CWND. However, downlink and uplink are often asymmetric due to, e.g., scheduling policies; as a result, RTT is known to be an inaccurate indicator for inferring congestion [27], [13]. Moreover, not all chipsets expose such detailed radio information to upper layers, which limits the practicality and deployability of this approach. The authors in [28], [29] introduce physical resource block (PRB) utilization as a practical congestion signal for mobile networks and show that it is closely coupled with queue buildup at the RLC layer of the BS. The proposed CCA, i.e., RAPID, achieves significant delay reduction with moderate goodput degradation and negligible packet loss [28]. However, RAPID requires abstract information about the number of active network flows, which limits its applicability mainly to private networks where such information is available. QueueTrack addresses this limitation by investigating whether queue dynamics can be inferred from end-host packet timing and delivery observations, without requiring direct access to the queue state at the BS.

queue, whereas an excess of delivered packets indicates that an existing RLC queue backlog is likely being depleted. A. Packet Arrival and Departure Processes

Figure 1. 5G edge testbed setup using the OAI platform and Ettus universal software radio peripheral (USRP) devices. The path bottleneck in this edge transport architecture lies at the RLC layer of the BS, as indicated on the schematic. The OctoClock provides time and frequency synchronization for the USRPs.

At the UE side, time is partitioned into intervals of duration δ seconds. The jth feedback interval is defined as [tj , tj + δ), where tj denotes its start time. We let ABS i (t) denote the cumulative number of packets offered to the BS for UE i up to time t, and DiUE (t) the cumulative number of packets delivered to UE i up to time t. Hence, for the jth interval, the number of offered packets is BS BS ∆ABS i,j = Ai (tj + δ) − Ai (tj )

(1)

whereas the corresponding number of delivered packets is III. S YSTEM M ODEL We consider a 5G edge architecture, as illustrated in Fig. 1, where the edge server (ES) is collocated with the BS at the network edge. The path bottleneck in this setup lies at the RLC layer of the BS. As depicted in Fig. 1, the BS adheres to a per-UE queueing policy, where each UE has its own dedicated queue at the BS [18]. Note that the major source of end-to-end delay is typically the QD at the RLC layer of the BS [30], [18], [9], [29]. Our interest is to detect the onset of queue buildup at the BS, as depicted in Fig. 1, in a practical and accurate manner via an innovative approach deployed in user space as an application running outside the operating system’s kernel. To this end, QueueTrack is implemented at the end hosts and does not require modifications to the 5G standard or network infrastructure. To infer the onset of queueing, the ES timestamps each packet by writing its send time in the packet payload using the system kernel time, enabling the UE to retrieve this information upon reception. The UE then uses this sender-side timing information together with packet arrival timing statistics to compute QBI and periodically report the resulting measurements back to the ES. QueueTrack can similarly be applied to uplink traffic by swapping the roles of the ES and UE. The perfect synchronization between the ES and the UEs is required only to precisely measure OWD as an evaluation reference for latency behavior and to derive offline groundtruth labels for supervised learning. OWD is not used as an input feature for the models or any other QueueTrack component. Furthermore, we assume that the RLC layer operates in unacknowledged mode, which is used for real-time services. IV. QBI M ETRIC : D EFINITION AND I NTERPRETATION QueueTrack infers queue buildup by comparing, over each feedback interval, the estimated number of packets offered to the BS with the number of packets received at the UE. When the offered packet count persistently exceeds the delivered packet count, packets are likely building up in the RLC

UE ∆Di,j = DiUE (tj + δ) − DiUE (tj )

(2)

Measuring ∆ABS i,j would require modifications to the BS or precise timing alignment between the ES, BS, and UE. To address this challenge, QueueTrack uses an end-host estimate of ∆ABS i,j over the jth feedback interval, denoted by Mi,j : ∆ABS i,j ≈ Mi,j

(3)

UE On the other hand, the delivered packet count, ∆Di,j , is measured directly at the UE and is denoted by Ni,j : UE = Ni,j ∆Di,j

(4)

Next, we denote by s1 , s2 , . . . , sn the send timestamps of packets received by UE i during the jth feedback interval. The inter-packet departure time (IPDT) is the time gap between consecutive packet departures at the ES. For n > 1, the empirical mean IPDT for UE i during the jth interval, denoted by µIPDTi (δj ), is defined as follows: 1 X (sk+1 − sk ) n−1 n−1

µIPDTi (δj ) =

(5)

k=1

We assume that backhaul is reliable, with negligible packet loss, and that its transport delay is small relative to the duration of the feedback interval δ. Furthermore, we assume that the send rate remains constant within each feedback interval. Under these assumptions, the number of packets offered to the BS can be approximated as: Mi,j =

δ µIPDTi (δj )

(6)

Note that bursty traffic, jitter, or rapid rate variations within a reporting interval can make µIPDT (δ) noisy. QueueTrack mitigates this by relying on short-history QBI features instead of single-interval estimates.

UE Bi,j = Bi,j−1 + ∆ABS i,j − ∆Di,j

1.5

45

OWD QBI 0.75

Drain 30

0 Buildup

15 0 3.5

Baseline 3.7

3.9

4.1

-0.75 -1.5 4.3

Time (sec)

(7)

If packets are discarded due to buffer overflow or retransmission failure, the gap between the number of offered and delivered packets not only captures the increase in Bi,j , but also accounts for packets that never reach the destination. Here, we focus on scenarios in which such packet losses are negligible. Substituting (3) and (4) into (7), we obtain:

60

QBI

Let Bi,j denote the number of packets that have been offered to the BS for UE i but have not yet been delivered to the UE by the end of the jth feedback interval. This quantity is not the exact RLC queue status, but it captures the packetcount mismatch that drives backlog buildup. Its dynamics can be written as:

OWD (ms)

B. Packet-Count Mismatch

Figure 2. Illustrative evolution of OWD and QBI during queue buildup and depletion. Each sample corresponds to a feedback report with δ = 50ms.

Therefore, the packet-count mismatch over the jth interval is

are being delivered than newly offered during this interval. As the queue backlog clears, both OWD and QBI return to their baseline behavior. This behavior shows that QBI is not only correlated with elevated delay, but also reflects the transition dynamics of queue buildup and depletion, supporting the use of short-history QBI features for detecting the onset of queueing.

∆Bi,j = Bi,j − Bi,j−1

V. E XPERIMENTAL S ETUP AND DATASET

Bi,j ≈ Bi,j−1 + Mi,j − Ni,j

≈ Mi,j − Ni,j

(8)

(9)

Thus, Mi,j − Ni,j reflects queue dynamics rather than the instantaneous queue occupancy. If Mi,j > Ni,j , the number of packets offered exceeds the number of packets delivered, implying that packets are building up at the BS. This situation can occur when the UE receives a smaller share of radio resources due to cross-traffic, degraded channel conditions, or increased hybrid automatic repeat request (HARQ) retransmissions. If Mi,j < Ni,j , more packets are delivered than offered within the interval, indicating that an existing backlog is being drained. Finally, if Mi,j ≈ Ni,j , the offered and delivered packet counts are roughly balanced, indicating that the newly offered packets neither build a new backlog nor increase the existing backlog at the BS. C. Queue Buildup Indicator While the packet-count mismatch in (9) reflects queue dynamics, its magnitude depends on the offered load. Thus, QueueTrack normalizes this mismatch using the estimated number of offered packets. For intervals with Mi,j > 0, QBI is defined as Mi,j − Ni,j (10) QBIi,j = Mi,j Note that QBI is upper bounded by 1 but has no lower bound because Ni,j can exceed Mi,j during periods when the queue is being drained. Fig. 2 provides an illustrative example of how QBI changes relative to OWD as the queue builds up and drains. In the absence of a persistent queue backlog, OWD remains low and QBI stays close to its baseline. As packets begin to accumulate, QBI increases, indicating that the offered packet count exceeds the delivered packet count. However, when the backlog starts to deplete, QBI decreases and becomes negative before OWD returns to its baseline, showing that more packets

In this section, we describe the testbed, the measurement process, and the dataset construction. A. 5G Testbed The experimental testbed is a 5G standalone network based on the OAI project (branch 2024.w38) for the core, BS, and UEs. It is configured to operate in the n78 frequency band using TDD mode with 6/3/1 D/U/M configuration, 40MHz channel bandwidth with PRBmax,slot =106, single layer transmission, and numerology 1 (30KHz subcarrier spacing with 0.5ms slot duration). This setup adheres to the default configurations of OAI. We use the oai-ext-dn container of OAI as the ES, which runs on the same machine as the 5G core and the BS. Each UE runs on a dedicated machine. The machines have identical hardware specifications (Intel Core i9-14900K CPUs with 128GB of DDR5 RAM) and run Ubuntu 22.04.5 LTS. The Ethernet NICs are connected through a MikroTik CRS309 switch and synchronized over a fiber-optic LAN via the precision time protocol (PTP) using the ptp4l program2 [31]. Moreover, we use the phc2sys program [32] to synchronize the system clock to the PTP hardware clock. The BS is connected to a USRP X310 software-defined radio (SDR), while the UEs use USRP B210 SDRs to communicate over the air. The USRPs run the open-source UHD driver (v4.6). Furthermore, all USRPs are synchronized using an OctoClock-G CDA-2990 to achieve a high-accuracy time and frequency reference, see Fig. 1. The UEs are placed at various positions, resulting in different channel conditions. Moreover, since the n78 band is the commercial 5G frequency band in the region where the experiments were conducted, 2 ptp4l is a Linux implementation of the PTP protocol according to IEEE standard 1588.

Table I E VALUATION SCENARIOS WITH TCP CROSS - TRAFFIC . Scenario 1 Cubic (1C) 1 BBR (1B) 2 Cubic (2C) 1 Cubic + 1 BBR (1C+1B)

TCP [30, 150]s [30, 150]s both: [30, 150]s Cubic: [30, 150]s, BBR: [60, 180]s

UDP [0, 180]s [0, 180]s [0, 210]s [0, 210]s

there is always potential interference from nearby mobile BSs and UEs. We develop the server- and UE-side codes in Python for our prototype implementation of QueueTrack. The ES generates iPerf-like UDP traffic towards the UEs and inserts a senderside timestamp into the packet payloads. Since the machines are tightly synchronized via the PTP protocol, this timestamp can be used to precisely measure the OWD at the UE. Furthermore, for cross-traffic, we generate iPerf-like TCP flows. B. Measurement and Data Collection We collect measurement traces through downlink experiments from the ES to the UE. In the single-UE baseline setting, the ES generates iPerf-like UDP traffic at a fixed send rate for 180s. We use a fixed packet size such that each IP datagram fits within the path maximum transmission unit (MTU) to avoid fragmentation. The UE sends feedback reports to the ES every δ seconds. We sweep the UDP send rate over {10, 20, 30, 40}Mbps and δ ∈ {25, 50, 75, 100}ms, and execute each configuration as an independent run. The UE records the send rate, receive rate, OWD, and QBI for each feedback report. Furthermore, we conduct experiments with TCP crosstraffic, where the ES generates one or more iPerf-like TCP flows using TCP Cubic and/or TCP BBR while the UDP flow under test remains active. The resulting dataset is used to evaluate the generalization of our models under complex and previously unseen congestion scenarios. TCP packets are timestamped using the same method as UDP packets, enabling OWD measurement for comparative analysis. For the multi-UE setup, the UDP flow under test operates at a fixed send rate in {10, 15, 20}Mbps, while additional UEs simultaneously generate competing TCP downlink traffic. The evaluated scenarios are summarized in Table I, where bracketed values denote the active time interval of each flow. For instance, [30, 150]s indicates that the flow starts at t = 30sec and terminates at t = 150sec. Traces are collected for feedback intervals δ ∈ {25, 50, 75, 100}ms. Recall that all multi-UE traces are withheld from training and used exclusively for evaluation. C. Dataset Preparation and Labeling The development of a persistent queue backlog corresponds to congestion and increases QD. This leads to an increase in OWD above its baseline value3 , which is primarily determined by processing delays at the BS and UE, the transmission time interval (TTI), and alignment delay [29]. We therefore define 3 The baseline OWD is below 10ms in our testbed.

Figure 3. QueueTrack framework, including offline model training and online QBI-based inference.

the onset of queueing as the transition from a low-delay regime to a persistent excess-delay regime, rather than isolated spikes in OWD [33]. We use a threshold-based labeling approach to derive the ground-truth congestion status from OWD. For each observation k, the label is defined as yk = 1{OWDk > τ }, where 1{·} represents the indicator function and τ denotes the delay threshold. Measurements with OWD exceeding τ are labeled as congested (1), while all remaining observations are labeled as non-congested (0). To evaluate both performance within the training regime and generalization to unseen regimes, we partition the dataset by traffic scenario. The training set contains only single-flow UDP traces. For each training trace, samples are ordered chronologically and then split: the first 75% is used for model training, and the remaining 25% serves as a temporal holdout set drawn from the same regime. The multi-flow traces, i.e., those with TCP Cubic and/or BBR cross-traffic, are excluded from training and used exclusively for final testing to evaluate whether QueueTrack generalizes to unseen traffic dynamics. VI. Q UEUE T RACK L EARNING P IPELINE This section describes the input feature construction, classification models, and evaluation protocol used by QueueTrack to detect queue buildup episodes. Fig. 3 provides an overview of the QueueTrack framework, highlighting the offline training and online inference phases. A. Feature Construction Since queue buildup is a temporal phenomenon, QueueTrack does not rely on a single QBI sample. An isolated positive QBI value may arise from short-term scheduling variation, channel fluctuation, or measurement noise, whereas persistent positive QBI values over multiple reporting intervals

B. Learning Models We evaluate QueueTrack using the following lightweight supervised classifiers implemented with the scikit-learn library [34]: LR, SVM with a radial-basis-function (RBF) kernel, and MLP. These models are used to determine whether a fixed-size feature vector derived from recent QBI values is sufficient for classifying the queue state. LR serves as a linear baseline, whereas SVM and MLP are designed to capture nonlinear dependencies among the QBI summary statistics and ordered-sequence features. OWD is used solely to generate offline congestion labels and is excluded as an input feature during both training and inference. Unless otherwise stated, the models are trained on single-flow UDP traces and evaluated on held-out test sets that include both UDP traces and previously unseen mixed-flow traces. The model hyperparameters are tuned using the training split and then held fixed across all reported test scenarios. A fixed decision threshold of 0.5 is applied to map the model outputs to binary decisions. C. Evaluation Protocol and Metrics We report precision, recall, F1 score, and precision-recall (PR) curves because queue buildup detection is an imbalanced binary classification problem, where false alarms and missed

1

Empirical CDF

indicate sustained queue buildup. Similarly, persistent negative QBI values indicate that the queue is being depleted. Let QBIi,j denote the QBI value reported by UE i during the jth feedback interval, as defined in Section IV. We define W as the number of consecutive reporting intervals, including the current interval, used for feature extraction. Using the current interval and the previous W − 1 intervals, QueueTrack constructs an input feature vector. The feature vector combines, over the W reporting intervals, (i) summary statistics of the recent QBI history and (ii) the ordered QBI sequence itself. The summary statistics include the mean QBI value QBIavg , the fraction of positive QBI values QBIpos , and the cumulative sum of negative QBI values QBIneg . QBIavg captures the persistent trend of the queue to grow or drain over the observation period. QBIpos characterizes how often the estimated offered packet count Mi,j exceeds the delivered packet count Ni,j during the same observation window, thereby indicating queue buildup. QBIneg reflects how the queue is being depleted and makes it possible to distinguish a queue that is already draining from one that is starting to build up. Furthermore, QueueTrack includes the ordered QBI sequence {QBIi,j , QBIi,j−1 , . . . , QBIi,j−W +1 }, which captures the recent temporal dynamics of the QBI trajectory. This sequence enables the classifiers to differentiate between persistent queue buildup, transient fluctuations, queue depletion, and recovery to baseline conditions. We also evaluated additional features, including the moving standard deviation, first-order differences, and exponentially weighted moving average of QBI. Since these features did not consistently improve performance, we use the feature set above to retain the key temporal structure while keeping the input representation compact.

0.75 0.5 = 20ms, early = 69% = 30ms, early = 83% = 40ms, early = 86%

0.25 0

0

250

500

750

1000

QBI early-warning lead (ms) Figure 4. Empirical CDF of QBI early-warning lead times for different OWD thresholds. The percentages indicate the fraction of high-OWD episodes preceded by a persistent positive-QBI signal. Experimental results.

detections have different operational consequences. Precision measures the fraction of predicted congestion alarms that are correct; low precision corresponds to an excess of unwarranted congestion responses. Recall captures the fraction of true congested intervals that are successfully identified; low recall indicates that the model fails to detect queue buildup episodes and may allow delay to grow unchecked. The F1 score, defined as the harmonic mean of precision and recall, is used as the primary scalar metric because it penalizes both false positives and undetected congestion events. PR curves complement the fixed-threshold F1 results by showing the trade-off between conservative high-confidence alarms and more aggressive detection settings. This is important because system designers may prefer different operating points depending on latency sensitivity and tolerance for false congestion signals. VII. E XPERIMENTAL R ESULTS This section evaluates whether QBI provides a practical short-history signal for detecting queue buildup at the network edge, rather than merely correlating with delay after congestion has already occurred. Since the RLC queue occupancy is typically unavailable to end hosts, we use congestion labels derived from OWD measurements as the ground truth. We conduct an in-depth evaluation using parameter sensitivity studies, out-of-regime generalization tests, precision-recall analysis, time-series inspection, and robustness evaluations under impaired UE feedback. The results show that QBI-derived features remain reliable across different feedback intervals δ, window lengths W , previously unseen TCP Cubic and BBR cross-traffic settings, and moderate feedback corruption, supporting the viability of QBI as a practical queue-state signal for detecting the onset of queueing at the BS. A. QBI Early-Warning Capability The behavior shown in Fig. 2 indicates that QBI can reveal queue-state changes before the corresponding changes are reflected in OWD. To assess the early-warning capability of QBI, we define a persistent high-OWD episode as a sequence of at least K consecutive feedback reports with OWD > τ , and a persistent positive-QBI period as a sequence of at least K consecutive feedback reports with QBI > 0. We set K = 2 empirically to filter out isolated fluctuations while preserving short-term queue changes. For each episode, we determine the

0.75 0.5 LR SVM MLP

0.25 0

(a) F1 score vs. reporting interval δ (b) F1 score vs. OWD threshold τ

QBI avg QBI pos QBI neg QBI( i) QBI( ) i-1 QBI( i-2) QBI( ) i-3 QBI( i-4) QBI( ) i-5 QBI( i-6) QBI( ) i-7

2

3

4

5

6

7

8

9 10

(c) F1 score vs. window size W

0.02 0.59 0.05 0.12 0.08 0.05 0.04 0.03 0.01 0.01 0.00

0.31 0.21 0.13 0.11 0.06 0.05 0.05 0.03 0.03 0.01 0.02

0.28 0.17 0.18 0.12 0.07 0.04 0.04 0.02 0.02 0.02 0.03

LR

SVM

MLP

0.6

0.4

0.2

Normalised importance

F1 score

1

0

(d) Feature importance heatmap

Figure 5. Single-flow UDP sensitivity and feature analysis, illustrating the impact of (a) the reporting interval δ, (b) the OWD threshold τ , and (c) the history window size W on detection performance, and (d) the importance of QBI-derived input features.

Figure 6. F1 scores under unseen mixed cross-traffic scenarios.

most recent persistent positive-QBI period that appears before OWD exceeds this threshold. We then define the lead time as the time interval between the start of this positive-QBI period and the subsequent crossing of the OWD threshold. Fig. 4 presents the empirical CDF of the resulting lead times. We adopt τ = 30ms as the default threshold: τ = 20ms tends to label even small delay increases as congestion, while τ = 40ms detects only more severe events and therefore yields fewer positive episodes. The sensitivity of the classifiers to the choice of τ is evaluated separately using the F1 scores in Section VII-B. With τ = 30ms, 173 out of 209 OWD episodes (83%) were preceded by a persistent positive-QBI signal. Across these 173 episodes, the median lead time was 149.8ms (interquartile range of 99.8-290.6ms), while the mean lead time was 225.7ms, with a 95% confidence interval of 193.7258.9ms. For the remaining episodes, a persistent positive-QBI signal either occurred only after the OWD threshold crossing or was not observed. B. QBI-Based Detection in a Single-Flow UDP Scenario We evaluate detection performance in a single-flow UDP setting to isolate the impact of key design parameters. Specifically, we examine the UE reporting interval δ, the history window length W , and the OWD congestion threshold τ . The results are summarized in Fig. 5. Unless varied on the x-axis, we use the default values of δ = 50ms, W = 8, and τ = 30ms. Fig. 5 (a) presents the F1 score as the reporting interval δ is varied. The models maintain high F1 scores over the tested range, indicating that QueueTrack does not depend on any specific feedback interval. Each bar’s height represents the aggregate F1 score across the four single-flow rate settings

in {10, 20, 30, 40}Mbps, while the vertical ranges indicate the minimum and maximum F1 values observed at these individual rates. These ranges therefore capture variation across load conditions rather than statistical uncertainty. Their limited spread further indicates that performance is stable across the tested single-flow rates. Since performance remains strong over the considered range, we adopt δ = 50ms for subsequent experiments as a representative operating point. This choice reflects a practical trade-off: a smaller δ increases the frequency of UE reports and thus uplink reporting overhead, whereas a larger δ reduces overhead at the cost of coarser temporal resolution. Fig. 5 (b) analyzes how sensitive QueueTrack is to the choice of OWD threshold τ , where samples are labeled as congested if OWD > τ . The threshold τ directly determines which samples are considered positive and how frequently positive samples occur. Smaller values of τ mark even modest delay increases as congestion, which diminishes the separation between classes. Larger values restrict the positive class to pronounced delay spikes, thereby increasing class imbalance. Over the range of thresholds considered, the models consistently achieve high F1 scores, with the best results occurring at intermediate thresholds. Since performance is close to its maximum for τ around 20-30ms, we select τ = 30ms in the subsequent experiments. Relative to τ = 20ms, this choice yields a slightly stricter notion of congestion by excluding samples with only slight delay increases, while still avoiding the scarcity of positive samples seen at higher thresholds. In practical deployments, τ should be viewed as a tunable, system- or service-specific parameter that dictates when elevated OWD is classified as congestion. Fig. 5 (c) shows the effect of the history window length W . Detection accuracy improves once W exceeds the shortest histories, indicating that the congestion is more reliably inferred from recent temporal evolution than from nearinstantaneous measurements alone. The gains then diminish as W increases further, with performance saturating at modest window lengths. This suggests that the most informative part of the QBI signal lies in the immediate past, while extending the temporal memory offers only marginal additional gains. Finally, Fig. 5 (d) shows the normalized importance of the QBI-based input features. The heatmap indicates that the

not strictly linear. Within this short interval, the MLP achieves slightly higher accuracy. For example, at t = 132sec, the MLP correctly identifies the onset of queueing, whereas the SVM misses it. Nonetheless, all three models exhibit a false positive around t = 133.5sec. For the 90sec interval in which all three flows are active, the F1 scores of LR, SVM, and MLP are 0.71, 0.77, and 0.78, respectively. D. Precision-Recall Analysis

Figure 7. Representative time-series comparison of model decisions.

models place the greatest emphasis on compact summary statistics and recent QBI history, rather than relying primarily on more distant QBI values. C. Generalization to Unseen Mixed-Flow Scenarios We investigate whether QBI-based detection can generalize beyond the single-flow UDP training setup. To this end, we analyze the behavior of QueueTrack under varying cross-traffic conditions. The models are trained exclusively on single-flow UDP traces and then evaluated on scenarios with previously unseen mixed cross-traffic, as follows: one TCP Cubic flow (1C), one TCP BBR flow (1B), two TCP Cubic flows (2C), and mixed TCP Cubic and BBR flows (1C+1B), see Table I. These scenarios match the multi-UE setup described in Section V-B. Fig. 6 reports the F1 scores for these settings, showing that the models maintain strong detection performance across all previously unseen scenarios. LR achieves F1 scores of about 0.74–0.82, while the nonlinear SVM and MLP classifiers improve performance to roughly 0.76–0.84. The best results are obtained under TCP BBR cross-traffic (1B), where SVM and MLP both achieve F1 scores of 0.83. The scenarios with only TCP Cubic cross-traffic are more challenging: the 1C case yields the lowest scores for all classifiers, and the 2C setting exhibits larger variability across loads, indicating that TCP Cubic induces queue dynamics that are less clearly distinguishable in the QBI feature space. Nevertheless, both SVM and MLP retain F1 scores above 0.80 in 2C and 1C+1B, demonstrating that QBI-based features capture a congestionstate signal that generalizes well to previously unseen crosstraffic conditions, rather than simply overfitting to the singleflow UDP training distribution. Fig. 7 illustrates a time-series performance comparison of QueueTrack with LR, SVM, and MLP models in detecting the onset of queueing for a representative 5G testbed trace. In this experiment, the UDP flow runs at 10Mbps, while two concurrent TCP flows, i.e., one TCP Cubic and one TCP BBR, serve as cross-traffic (1C+1B). LR identifies the congestion episodes, but also produces false positives at t = 131.5sec and t = 133.5sec. The nonlinear SVM and MLP models track the onset of OWD increases more tightly, indicating that the relationship between QBI dynamics and the queueing state is

The PR curves in Fig. 8 provide a more detailed view of generalization than the aggregate F1 scores alone. Across unseen mixed-flow scenarios, the QBI-based detectors maintain precision and recall, avoiding the shift toward low precision and high recall that would suggest overfitting to the singleflow UDP training configuration. Moreover, SVM and MLP preserve a broad operating range where precision remains high as recall increases, indicating that QBI captures congestionstate structure that remains stable under varying cross-traffic conditions. This behavior is most pronounced for TCP BBR (1B), see Fig. 8 (b), where the nonlinear detectors maintain near-perfect precision over much of the recall range. This suggests that QBI provides a strong representation of the queue dynamics induced by TCP BBR. The scenarios with TCP Cubic cross-traffic are more challenging, see, e.g., Fig. 8 (a). In these cases, the curves bend downward earlier, particularly at high recall, indicating that the detection of more congestion episodes comes at the cost of a higher false positive rate. Notably, in the 2C (Fig. 8 (c)) and 1C+1B (Fig. 8 (d)) scenarios, the curves degrade smoothly rather than abruptly, showing that the detector remains effective as the number of flows increases and the cross-traffic becomes more heterogeneous. From a deployment perspective, QBI does not impose a single fixed operating point: system designers can select a conservative threshold for high-confidence congestion alerts or relax the threshold when broader congestion coverage is preferred. The stable precision–recall tradeoff observed under previously unseen cross-traffic conditions shows that QBI offers a reliable signal for the onset of queueing at the BS when the cross-traffic is not known in advance. E. Robustness Under Feedback Impairments QueueTrack relies on periodic UE feedback to reconstruct QBI-based features. However, in practice, these feedback reports may be imperfect due to uplink packet loss or measurement noise. For instance, the QBI computation assumes that the send rate remains constant within each reporting interval δ. This assumption can be violated by rate adaptation at the transport layer, operating-system scheduling delays, or other sources of timing noise. We evaluate the robustness of QueueTrack under two feedback-corruption scenarios. First, we introduce a relative error into M at each feedback interval, with ∆M/M ∈ {−10, −7, −5, −3, 0, 3, 5, 7, 10}%. For each corrupted value of M , we recompute QBI using Eq. (10) and rebuild the input features based on the resulting corrupted QBI sequence. Second, we model independent feedback loss

1

0.75

0.75

0.75

0.75

0.5 LR SVM MLP

0.25 0

0

0.25

0.5

0.75

0.5 0.25 0

1

LR SVM MLP

0

0.25

Recall

0.5

0.75

1

Recall

(a) 1 TCP Cubic flow (1C)

Precision

1

Precision

1

Precision

Precision

1

0.5 LR SVM MLP

0.25 0

0

0.25

0.5

0.75

Recall

(b) 1 TCP BBR flow (1B)

(c) 2 TCP Cubic flows (2C)

1

0.5 LR SVM MLP

0.25 0

0

0.25

0.5

0.75

1

Recall (d) TCP Cubic and BBR flows (1C+1B)

Figure 8. Precision-recall performance under different cross-traffic scenarios for LR, SVM, and MLP classifiers.

1

Precision

F1 Score

1 0.75 0.5 0.25 0 -10

LR SVM MLP

-5

0

5

0.75 0.5 0.25 0 -10

10

(a) F1

F1 Score

Recall

0.5 LR SVM MLP

-5

0

5

0.5 0.25

1

0.75

0.75

LR SVM MLP

0 0 0.1 0.2 0.3 0.4 0.5 (e) Precision

LR SVM MLP

(d) F1

Recall

Precision

10

0 0 0.1 0.2 0.3 0.4 0.5

10

1

0.25

5

0.75

(c) Recall

0.5

0

1

0.75

0 -10

-5

(b) Precision

1

0.25

LR SVM MLP

0.5 0.25

LR SVM MLP

0 0 0.1 0.2 0.3 0.4 0.5 (f) Recall

Figure 9. Robustness under impaired UE feedback. Panels (a)–(c) inject multiplicative error into the offered packet count M , while panels (d)–(f) independently drop feedback reports with Bernoulli probability p.

by dropping each feedback report with Bernoulli probability p ∈ {0, 0.01, 0.05, 0.10, 0.20, 0.30, 0.40, 0.50}. Dropped reports are imputed using the most recent UE feedback sample. Fig. 9 reports the resulting F1 score, precision, and recall. In the relative-error analysis of M , QueueTrack is more sensitive to overestimation than to underestimation. As illustrated in Fig. 9 (b), precision drops for positive ∆M/M , indicating that QueueTrack predicts congestion more aggressively and generates additional false positives. Negative perturbations have the opposite effect: QueueTrack behaves more conservatively and predicts congestion less often, increasing the num-

ber of false negatives and reducing recall, as shown in Fig. 9 (c). The MLP is more tolerant to moderate positive bias than LR and SVM. As depicted in Fig. 9 (a), at ∆M/M = 3%, the MLP F1 score remains close to its unperturbed value (≈ 0.82 versus ≈ 0.84), while LR and SVM drop to approximately 0.70 and 0.72, respectively. At ∆M/M = 5%, all models degrade, with F1 scores of roughly 0.66, 0.66, and 0.72 for LR, SVM, and MLP, respectively. Overall, positive error in M is more harmful than comparable negative error because it biases the reconstructed QBI sequence toward apparent backlog growth, increasing false positives. In contrast, feedback loss leads to a gradual decline in F1 scores with substantial degradation emerging only when p > 0.20, see Fig. 9 (d). As p increases, precision drops more sharply than recall, see Fig. 9 (e) and (f), because the observation window contains fewer up-to-date feedback measurements, causing outdated values to be propagated over longer intervals. This temporal mismatch can make the inferred queue dynamics appear more congested than they actually are, leading to more false positives and consequently reducing precision. VIII. C ONCLUSION This paper presented QueueTrack, a practical end-host framework that infers bottleneck queue dynamics using endpoint-observable measurements to detect the onset of queueing in mobile networks. QueueTrack computes a queue buildup indicator, denoted QBI, from packet-level timing statistics and uses finite-history QBI features with lowcomplexity learning models to identify queue-state transitions at the RLC layer of the BS. The framework operates without requiring tight synchronization between end hosts or modifications to existing network infrastructure or 3GPP standards. We implemented and evaluated the complete QueueTrack ML pipeline on an OAI 5G testbed. The evaluation covered singleflow UDP settings, multi-UE scenarios with previously unseen TCP Cubic and BBR cross-traffic, and impaired feedback conditions. The results show that QBI provides an effective signal for detecting the onset of queueing. Under challenging unseen traffic scenarios, QueueTrack maintains reliable detection performance, with nonlinear models such as SVM and MLP achieving F1 scores around 80%. The robustness evaluation further shows that QueueTrack is resilient to moderate feedback loss, while positive bias in the estimated offered

packet count can increase false positives. The experimental results demonstrate that QueueTrack can support low-latency CCAs, as well as network telemetry, runtime diagnostics, and network monitoring in mobile networks. We extend QueueTrack from queueing-onset detection to near-future queueingonset prediction using an echo state network [35]. As future work, we intend to evaluate the robustness of QBI and QueueTrack under different MAC scheduler configurations, scheduler hyperparameter settings, and mobility conditions. ACKNOWLEDGMENT This work was supported by the DAIS project under Grant Agreement No. 101007273, the HICONNECTS project under Grant Agreement No. 101097296, and the Dutch RVO under TSH project No. 21007. R EFERENCES [1] W. Saad, M. Bennis, and M. Chen, “A Vision of 6G Wireless Systems: Applications, Trends, Technologies, and Open Research Problems,” IEEE Network, vol. 34, no. 3, pp. 134–142, 2020. [2] I. F. Akyildiz and H. Guo, “Wireless Communication Research Challenges for Extended Reality (XR),” ITU Journal on Future and Evolving Technologies, vol. 3, no. 2, pp. 273–287, 2022. [3] C. She, T. Q. Duong, T. Q. S. Quek, H. Viswanathan, and D. LopezPerez, “Guest Editorial: Intelligent Ultra-Reliable and Low-Latency Communications in 6G,” IEEE Wireless Communications, vol. 30, no. 2, pp. 12–13, 2023. [4] Adeia, “Immersive Media: Bringing Science Fiction to Commercial Reality,” Adeia, White Paper, May 2023. [5] SK Telecom, “5G Lessons Learned, 6G Key Requirements, 6G Network Evolution, and 6G Spectrum,” SK Telecom, White Paper, Aug 2023. [6] H. Hassani, F. Gringoli, and D. J. Leith, “Quick & Plenty: Achieving Low Delay & High Rate in 802.11ac Edge Networks,” Computer Networks, vol. 187, p. 107820, 2021. [7] Y. Xie and K. Jamieson, “NG-Scope: Fine-Grained Telemetry for NextG Cellular Networks,” Proceedings of the ACM on Measurement and Analysis of Computing Systems, vol. 6, no. 1, pp. 1–26, Feb 2022. [8] N. Cardwell, Y. Cheng, C. S. Gunn, S. Hassas Yeganeh, and V. Jacobson, “BBR: Congestion-Based Congestion Control,” Communications of the ACM, vol. 60, no. 2, pp. 58–66, Jan 2017. [9] B. Briscoe, K. De Schepper, M. Bagnulo, and G. White, “Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture,” RFC 9330, Jan 2023. [10] D. De Vleeschauwer, T. J. Wassing, K. De Schepper, C.-Y. Chang, and C. Papagianni, “Application-Driven Traffic Differentiation,” in Proceedings of the Joint European Conference on Networks and Communications & 6G Summit (EuCNC/6G Summit), 2024, pp. 1049–1054. [11] A. S. Tanenbaum, N. Feamster, and D. J. Wetherall, Computer Networks, 6th ed. Pearson, 2021. [12] S. Ha, I. Rhee, and L. Xu, “CUBIC: A New TCP-Friendly High-Speed TCP Variant,” ACM SIGOPS Operating Systems Review, vol. 42, no. 5, pp. 64–74, July 2008. [13] D. Chefrour, “One-Way Delay Measurement From Traditional Networks to SDN: A Survey,” ACM Computing Surveys, vol. 54, no. 7, pp. 1–35, July 2021. [14] Y. Xie, F. Yi, and K. Jamieson, “PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer Bandwidth Measurements,” in Proceedings of the ACM SIGCOMM Conference, Aug 2020, pp. 451–464. [15] H. Wan, X. Cao, A. Marder, and K. Jamieson, “NR-Scope: A Practical 5G Standalone Telemetry Tool,” in Proceedings of the 20th International Conference on Emerging Networking EXperiments and Technologies (CoNEXT), 2024, pp. 73–80. [16] H. Wan and K. Jamieson, “Evolving Mobile Cloud Gaming with 5G Standalone Network Telemetry,” 2024. [Online]. Available: https://arxiv.org/abs/2402.04454 [17] K. K. Ramakrishnan, S. Floyd, and D. L. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” RFC 3168, Sep 2001.

[18] M. Irazabal and N. Nikaein, “TC-RAN: A Programmable Traffic Control Service Model for 5G/6G SD-RAN,” IEEE Journal on Selected Areas in Communications, vol. 42, no. 2, pp. 406–419, 2024. [19] N. Nikaein, M. K. Marina, S. Manickam, A. Dawson, R. Knopp, and C. Bonnet, “OpenAirInterface: A Flexible Platform for 5G Research,” ACM SIGCOMM Computer Communication Review, vol. 44, no. 5, pp. 33–38, Oct 2014. [20] L. Xu, K. Harfoush, and I. Rhee, “Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks,” in Proceedings of the 23rd Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), vol. 4, 2004, pp. 2514–2524. [21] V. Arun and H. Balakrishnan, “Copa: Practical Delay-Based Congestion Control for the Internet,” in Proceedings of the Applied Networking Research Workshop (ANRW), 2018, p. 19. [22] X. Xie, X. Zhang, S. Kumar, and L. E. Li, “piStream: Physical Layer Informed Adaptive Video Streaming over LTE,” in Proceedings of the 21st Annual International Conference on Mobile Computing and Networking (MobiCom), 2015, pp. 413–425. [23] X. Xie, X. Zhang, and S. Zhu, “Accelerating Mobile Web Loading Using Cellular Link Information,” in Proceedings of the 15th Annual International Conference on Mobile Systems, Applications, and Services (MobiSys), 2017, pp. 427–439. [24] S. Park, J. Lee, J. Kim, J. Lee, S. Ha, and K. Lee, “ExLL: An Extremely Low-Latency Congestion Control for Mobile Cellular Networks,” in Proceedings of the 14th International Conference on Emerging Networking EXperiments and Technologies (CoNEXT), 2018, pp. 307–319. [25] J. Shin, G. Lee, J. Paek, and S. Bahk, “César: Cellular Resource Scheduling-Aware Congestion Control,” in Proceedings of the IEEE Conference on Computer Communications (INFOCOM), May 2025, pp. 1–10. [26] J. Larrea, T. Shreedhar, A. Niemi, A. Sefiane, and M. K. Marina, “BISCAY: Practical Radio KPI Driven Congestion Control for Mobile Networks,” in Proceedings of New Ideas in Networked Systems (NINeS), 2026, pp. 15:1–15:32. [27] A. Pathak, H. Pucha, Y. Zhang, Y. C. Hu, and Z. M. Mao, “A Measurement Study of Internet Delay Asymmetry,” in Proceedings of the 9th International Conference on Passive and Active Network Measurement (PAM), 2008, pp. 182–191. [28] H. Hassani, S. M. Heemstra de Groot, I. G. Niemegeers, K. C. Joshi, and G. Exarchakos, “RAPID: Proactive Rate Control for Enabling High Data Rate and Low Latency in 5G Edge Networks,” in Proceedings of the IEEE Conference on Computer Communications (INFOCOM) Workshops, 2025, pp. 1–6. [29] ——, “One-Way Delay Model for 5G Low Latency, High Data Rate Communications,” in Proceedings of the IEEE International Conference on Communications (ICC), 2025, pp. 5859–5865. [30] F. Ronteix-Jacquet, “Reducing Latency and Jitter in 5G Radio Access Networks,” Ph.D. dissertation, Ecole nationale supérieure MinesTélécom Atlantique, 2022. [31] (2025) ptp4l(8) - Linux Man Page. Accessed: May 10, 2026. [Online]. Available: https://linux.die.net/man/8/ptp4l [32] (2025) phc2sys(8) - Linux Man Page. Accessed: May 10, 2026. [Online]. Available: https://linux.die.net/man/8/phc2sys [33] P. Goyal, A. Agarwal, R. Netravali, M. Alizadeh, and H. Balakrishnan, “ABC: A Simple Explicit Congestion Controller for Wireless Networks,” in Proceedings of the USENIX Symposium on Networked Systems Design and Implementation (NSDI), 2020, pp. 353–372. [34] F. Pedregosa, G. Varoquaux, A. Gramfort, V. Michel, B. Thirion, O. Grisel, M. Blondel, P. Prettenhofer, R. Weiss, V. Dubourg, J. Vanderplas, A. Passos, D. Cournapeau, M. Brucher, M. Perrot, and E. Duchesnay, “Scikit-learn: Machine Learning in Python,” Journal of Machine Learning Research, vol. 12, pp. 2825–2830, 2011. [35] A. Karnam, H. Hassani, K. C. Joshi, S. M. Heemstra de Groot, I. G. Niemegeers, and G. Exarchakos, “PINOCCHIO: Queueing-Onset Prediction in Mobile Edge Networks Using Reservoir Computing,” in Proceedings of the Applied Networking Research Workshop (ANRW), 2026, pp. 24–26.

Related documents

• Counting Triangles in Graph Streams with Repeatable and Forgettable Edges#1014988
• Reducing Runtime Overhead in Distributed Congestion Monitoring Systems#356126
• Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences#502708
• The DOCSIS Queue Protection Algorithm to Preserve Low Latency#172750
• Scheduling in Multi-Hop Wireless Networks With Deadlines#120460