RAPID: Proactive Rate Control for Enabling High Data Rate and Low Latency in 5G Edge Networks

RAPID: Proactive Rate Control for Enabling High Data Rate and Low Latency in 5G Edge Networks Hamid Hassani, Sonia M. Heemstra de Groot, Ignas G. Niemegeers, Kishor C. Joshi, George Exarchakos

arXiv:2610.13749v1 [cs.NI] 9 Oct 2026

Eindhoven University of Technology, The Netherlands {h.hassani,sheemstradegroot,i.g.m.m.niemegeers,k.c.joshi,g.exarchakos}@tue.nl

Abstract—Many 6G use cases such as tactile Internet and eXtended reality applications would simultaneously require a high data rate and low latency wireless connectivity. It is increasingly being realized that the current transport protocols relying on packet loss and delay are insufficient to satisfy the data rate and latency requirements of such applications. To address this problem, we propose RAPID, a transport layer solution designed for private 5G edge networks, where the bottleneck is located at the base station. We show that by regulating the send rate to maintain a target physical resource block utilization, we can achieve high data rate, low latency communication. We design a simple yet effective policy that adapts to the dynamic nature of wireless channel conditions. In a multi-UE scenario with two RAPID flows and one TCP Cubic flow, our testbed results show that RAPID flows achieve significant improvements in one-way delay, i.e., 72x and 55x lower compared to TCP Cubic, with negligible packet loss at the cost of modest goodput reductions of 16% and 27%, respectively.

I. Introduction Next-generation applications such as eXtended reality (XR), holographic telepresence, and telemedicine operations come with strict requirements for communication in terms of data rate, latency, and reliability [1]. These requirements, however, cannot be entirely met by current 5G or 802.11ax (Wi-Fi 6) networks that primarily focus on physical and link layer technologies, see, e.g., [2]. It is increasingly being realized to have well-designed transport layer protocols to fulfill the stringent requirements of nextgeneration applications. For example, [3] has compared the end-to-end performance of multiple congestion control (CC) algorithms in a commercial LTE network (AT&T), and showed that the performance variance among the CC mechanisms might be significant. This measurement, along with many similar measurements conducted using 3GPP or IEEE 802.11 access technologies, see, e.g., [4], [5], provide additional evidence that highlights the limitations of existing transport layer solutions in satisfying the demanding requirements of next-generation applications. The requirement for major upgrades to current transport protocols is also reflected in initiatives such as L4S [6], Google BBR [7], Google QUIC [8], and the OpenFastPath Alliance [9]. Furthermore, ETSI has set up the Industry Specification Group on Next Generation Protocols (NGP ISG) to study the next-generation protocols for 5G [10]. According to the applied congestion signal, the CC mechanisms at the transport layer are categorized into

two main groups: loss-based and delay-based approaches, see Section II. These solutions, however, may prove insufficient for next-generation applications that would require both high data rate and low latency, see, e.g., [11]. The use of packet loss as a congestion signal is not ideal for achieving low latency and high data rate, as it triggers action, i.e., adjusting the send rate, only after queue overflow occurs, leading to high queueing delay (QD). On the other hand, for delay-based approaches, measurements of one-way delay (OWD) might be used to infer the onset of queueing and adjust the send rate, but measuring OWD is known to be challenging due to, e.g., clock offset and skew between server and client [5], as is inference of queueing from OWD. The use of roundtrip time (RTT) to estimate the onset of queueing is also known to be inaccurate when there is queueing in the reverse path, i.e., asymmetric forward and reverse paths [12]. There are alternative approaches, such as using networkwide sniffing [3], [13] to measure cell-wide resource utilization and gauge available capacity, or using explicit congestion notification (ECN) protocols. However, these strategies are often impractical due to deployment and upgrade difficulties. For example, solutions that rely on ECN, such as L4S [6], require extensive updates to network infrastructure and end-user devices, making widespread adoption challenging. To address the above challenges, we propose RAPID, a novel user-space transport solution designed to achieve high data rate and low latency communication over 5G edge networks. Our main contributions can be summarized as follows: • We show that by regulating the downlink send rate to maintain a target physical resource block (PRB) utilization, it is possible to avoid persistent queue backlogs at the base station (BS) and, hence, to realize high data rate, low latency communication in a robust and practical fashion. • This approach offers significant advantages in terms of flexibility, support for innovation, and ease of rollout, due to the high efficiency achievable in user space, supported by modern kernels. It can be seamlessly integrated as an application on end devices, i.e., servers and user equipment (UEs), without requiring any changes to the existing BSs.

The 5G testbed evaluation using OpenAirInterface (OAI) and Ettus USRPs, see Fig. 1 (b), in a multiUE scenario, with two UEs operating RAPID and one UE using a TCP Cubic flow, shows that the RAPID flows achieve 72x and 55x reductions in OWD with negligible packet loss, while incurring 16% and 27% deteriorations in goodput, respectively, compared to the TCP Cubic flow. Note that the 5G QoS model also supports nonguaranteed bit rate (Non-GBR) flows for low-latency eMBB applications such as XR [14]. For instance, NonGBR QoS flows with a 5G QoS Identifier (5QI) value of 80 are proposed for XR applications with a packet delay budget (PDB) of 10ms when the network is not congested. While these QoS mechanisms provide performance targets, they alone cannot prevent network congestion. Our transport layer solution complements the 5G QoS model by enabling end devices to proactively adjust their send rates to avoid congestion and maintain optimal performance, facilitating the realization of the performance targets specified by 5QI parameters. The remainder of this paper is structured as follows: In Section II, we discuss related work. Next, we present the system architecture in Section III, followed by an analysis of latency in Section IV. We then explain how PRB utilization can be used to infer the onset of queueing at the BS in Section V. In Section VI, we design a control policy to achieve high data rate and low delay communication in private 5G edge networks. In Section VII, we present experimental results. Next, we discuss limitations and future work in Section VIII and conclude the paper in Section IX. •

II. Related Work A. Congestion Control The delay-based CC mechanisms such as TCP Vegas [15] and TCP BBR [7] use RTT (/minimum RTT) measurements to adjust the send rate and avoid the queue build-up in the path bottleneck links. This way, they target low latency communication; however, several studies in cellular networks have shown that they fall short in achieving good performance, see, e.g., [3], [4], [16], [17], because, e.g., the forward path and reverse path are not typically identical due to queueing in the reverse path [12]. The CC mechanisms that use packet loss as the congestion signal, e.g., TCP BIC [18] and TCP Cubic [19], are not suitable for low delay communication since they increase the send rate to fill up the bottleneck queues until they see packet losses, which result in high latency. TCP BBR [7] uses the measurements of RTT and throughput to estimate the bottleneck bandwidth and avoid queue build-up. While the Linux kernel only supports BBRv1, Google plans to submit BBRv3 for inclusion in mainline Linux [20]. Note that BBR is not specifically designed for wireless networks, and multiple studies, see, e.g., [3], [5], [17], [21], show that achieving low latency in

3GPP and IEEE 802.11 networks is challenging via BBR. Once Linux (and network simulators like NS3) upgrades to BBRv3, the performance of the latest release of this rate control mechanism can be widely evaluated; however, initial work like [22] raises concern about its performance. B. Congestion Control for LTE/5G Networks The primary focus of relevant literature is on various approaches to estimate the available bandwidth to, e.g., adjust the TCP congestion window (CWND). For example, piStream [23] adopts an energy-based spectrum monitor to estimate the available bandwidth in LTE networks. While it does not require decoding the control channel, such power measurements are vulnerable to interference and thus result in significant estimation error [3]. In addition, this method needs fine-grained per-subcarrier channel information, which can be acquired only via radio monitoring software [16]. [16] presents a tool called CLAW that can estimate the LTE cell-wide resource utilization based on the physical layer information, such as RSRQ (Reference Signal Received Quality), available on unmodified commodity (but rooted) mobile handsets. CLAW needs around one RTT to estimate the available bandwidth. However, results in [16] show that the predictive power of signal strength is relatively limited [17]. Furthermore, energy measurements have typically resulted in significant estimation errors due to interference [3]. ExLL [4] analyzes the patterns in packet reception in short time windows, i.e., at an LTE subframe granularity, to infer the LTE link bandwidth. This transport layer approach relies on end-to-end statistics so that it is sensitive to network dynamics and can potentially estimate the available bandwidth inaccurately [17]. A state-of-the-art solution, as outlined in [3], [17] for LTE and [13], [24] for 5G, proposes to increase the send rate based on the unallocated PRBs in the previous slots to maximize throughput and maintain low delay while it does not explicitly discuss its rate control policy. This approach necessitates knowledge of cell-wide PRB utilization, which they obtained by introducing passive sniffers in different locations to capture and decode the control channel over the air interface [3], [13], [17], [24]. Nonetheless, this approach has performance concerns, and decoding the control channels is not a practical solution [23]. III. System Architecture In this paper, we consider the edge architecture of the type illustrated in Fig. 1 (a), where the edge server (ES) and the user plane function (UPF) are collocated with the BS, see, e.g., Fig. 3 in [25]. We assume that the BS serves as the bottleneck in an end-to-end path from the ES to UEs, due to the rate mismatch between the wired backhaul and the air interface. As depicted in Fig. 1 (a), the BS adheres to the per-UE queueing policy, meaning that each UE has its dedicated queue at the BS [26].

(a) System model

(b) 5G testbed

Fig. 1. (a) Edge transport architecture with a bottleneck in the wireless link, i.e., at the RLC layer of the BS, as indicated on the schematic. (b) 5G testbed.

Our interest is in achieving high data rate and low latency in 5G edge networks by effectively managing end-to-end connections via an enhanced transport layer protocol. The key concept involves preventing the buildup of a persistent queue backlog at the BS in the RLC buffer to keep the OWD between the edge application and the UE low while fully utilizing the available link capacity. While our current focus is on the downlink, extending this approach to the uplink is a relatively straightforward process. The key difference is that for the uplink, the ES first updates the uplink send rates of UEs and then distributes this information to UEs for the subsequent time interval. A. Assumptions 1) System Model: The network under consideration is a private 5G network where all traffic flows are under the administration of the ES. The ES is located close to the end users, i.e., at the network edge, and has a centralized overview of network flows. The ES can also function as a proxy gateway, routing traffic flows to and from UEs. This enables the implementation of novel transport layer protocols over the path between the proxy and UEs. 2) Data Flow: We use the UDP transport protocol to deploy our approach as an application that runs on both the ES and UEs. The downlink traffic type is considered to be identical, e.g., best effort, so that all traffic flows towards a UE are carried by a single data radio bearer (DRB), thus sharing the same RLC buffer at the BS. In addition, we presume a full-buffer model, where there is always packet(s) queued in the RLC buffer of each UE, precisely at scheduling decisions, see, e.g., [27]. IV. Latency Analysis To design an effective low latency rate control policy, we focus on the OWD of packets transmitted from the ES to UEs within the 5G edge network presented in Fig. 1 (a). The OWD includes several random components, including processing time, queueing delay, transmission delay, etc. However, the most significant (and often overlooked) source of delay is typically the QD [6] at the RLC layer of the BS [26], [28]. Our analysis, therefore, excludes other sources of delay. The QD is influenced by various factors, including the underlying access technology and

50 5

25 0 10

50

90

130

0 170

PRB (%) OWD (ms) Loss (%)

20

30 20

15 10

10 5 5

OWD and Loss

10

25

PRB Utilization

75

15

PRB (%) OWD (ms) Loss (%)

OWD and Loss

PRB Utilization

100

0 10 15 20 25 30 35 40

Send Rate (Mbps)

Send Rate (Mbps)

(a) Single-UE Scenario

(b) Multi-UE Scenario

Fig. 2. NS3 simulations using the 5G-LENA module [29] with the NrMacSchedulerTdmaRR scheduler. BW = 40MHz, UDP traffic, MCS = 28, 60sec of simulation. (a) single-UE scenario, (b) 4 UEs located at the same distance from the BS with equal send rates.

the number of earlier-arriving packets in the same queue awaiting transmission over the wireless link. The QD is also significantly affected by the MAC scheduling policy, the queue occupancy of other users, buffer sizes, and the channel quality of connected UEs to the BS. V. Low Delay High Data Rate Operation We define the PRB utilization of UE i during the time interval τ , denoted by PRBi,τ , as follows: PRBi,τ = PRBmax,slot ·

PRBalloc,i,τ PRBtotal,τ

(1)

where PRBalloc,i,τ is the number of allocated PRBs to UE i and PRBtotal,τ represents the total number of PRBs in the time interval τ . PRBmax,slot denotes the maximum number of available PRBs per slot, which is determined by the bandwidth and the selected numerology. Fig. 2 depicts the PRB utilization (%), one-way delay, and packet loss vs. the send rate for a range of network configurations from the NS3 network simulator. A number of key features are evident from the simulation results. Firstly, as the send rate increases, the PRB utilization increases monotonically until it reaches the maximum value. Fig. 2 (a) shows a scenario in which only one UE is connected to the BS, where all available PRBs can potentially be allocated to that UE, resulting in 100% PRB utilization. However, in the case of multiple UEs, the PRBs must be shared among UEs via the MAC scheduler. Fig. 2 (b) presents a scenario where identical flows are generated for 4 UEs, each located at an equal distance from the BS (in a circle) with the same modulation and coding scheme (MCS) and channel model in NS3. Note that since the plots for all UEs are nearly identical under these conditions, we only show the plot for one representative UE in Fig. 2 (b). We can observe that Fig. 2 (a) and (b) follow the same pattern, except that in Fig. 2 (b), the maximum PRB utilization for each UE reaches ≈ 25%. Secondly, the OWD increases monotonically with the send rate, initially increasing gradually but then increasing sharply as the send rate approaches the link capacity, leading to the onset of network congestion. Observe that the sharp increase in OWD coincides with PRB utilization

approaching its upper limit and with the onset of packet loss. We analyze the behavior in Fig. 2 in more detail. Assume that packets are transmitted by the sender in a paced fashion. On arriving at the BS, they are queued at the RLC buffer until the next transmission opportunity. The queue occupancy increases roughly linearly since the arriving packets are paced (have roughly constant inter-arrival times). Upon a transmission opportunity, the queued packets are assembled into a transport block (TB) and transmitted by the PHY layer. The maximum number of packets that can be aggregated within a TB is determined by the number of allocated PRBs by the MAC scheduler and the selected MCS. If the required number of PRBs by a UE in a given slot is less than the maximum available PRBs, the queue backlog is cleared. Otherwise, packets should wait for the next slot(s) to gain transmission opportunities. Thus, queueing delay and PRB utilization are correlated, and this is what we see in Fig. 2. The data in Fig. 2 suggests that if we could operate the system at a PRB utilization close to the maximum achievable capacity, we can obtain a high send rate while maintaining low delay. The approach we suggest here is based on this observation. Note that operating at less than the maximum possible PRB utilization incurs a throughput cost and there is therefore a trade-off between delay and data rate. However, Fig. 2 indicates that this trade-off is quite favorable, i.e., that low delay comes at the cost of only a relatively small reduction in data rate compared to the maximum possible. VI. Controlling Delay We proceed by introducing a simple feedback loop that adjusts the downlink send rate at the ES to maintain a selected target PRB utilization. This value is determined by, e.g., the QoS requirements of the application. At the UE side, time is partitioned into intervals of duration δ seconds. UE i measures its PRB utilization within the interval δj (PRBi,j ), see (1), and reports it to the ES via UDP every δ seconds. The ES then uses the received feedback from UE i to adjust its send rate ri . At the ES, time is divided into intervals of duration ∆ seconds (∆ > δ). We let Ni,k denote the set of feedback reports delivered by UE i in interval ∆k . Next, Algorithm 1 Feedback loop adjusting send rate ri to regulate µPRBi (∆). Initialize k ← 1 while true do sleep(∆) ∑ µPRBi (∆k ) ← |N1i,k | j∈Ni,k PRBi,j ri,k+1 ← ri,k − K · (µPRBi (∆k ) − Pϵ,i ) k ←k+1 end while

∑ we denote µPRBi (∆k ) = |N1i,k | j∈Ni,k PRBi,j the average PRB utilization of UE i in the time interval ∆k . If the observed µPRBi (∆k ) for UE i is less than its target value Pϵ,i , the ES increases its transmit rate ri and decreases it if µPRBi (∆k ) > Pϵ,i . This feedback controller is implemented using the pseudo-code shown in Algorithm 1. Note that the feedback gain K > 0 balances the convergence rate and stability of the proposed rate adaptation mechanism. A. Selecting Design Parameter Pϵ In this paper, without loss of generality, we assume that m RAPID traffic flows have identical QoS requirements and therefore share the same target PRB utilization, i.e., Pϵ,i = Pϵ for i ∈ {1, . . . , m}. In scenarios where RAPID flows have different QoS requirements, Pϵ,i can be readily adjusted for each UE accordingly. To assess the performance of the system near the network saturation point and under full load, we focus on the maximum achievable PRB utilization per UE. We set Pϵ = PRBmax,slot /n, where n ≥ m represents the total number of active downlink flows, including both RAPID and non-RAPID traffic flows. Note that, in private 5G networks, the ES is aware of the number of traffic flows, thus the value of n is readily available. While this may not hold true for public networks, such information can be obtained in public networks through network telemetry tools such as NR-Scope [24]. The reason for considering equal PRB allocation among UEs, i.e., dividing PRBmax,slot by n, is due to the steadystate behavior of widely used proportional-fair (PF) schedulers in cellular networks [16], [30]. While some proprietary PF schedulers may implement more sophisticated policies, the logarithmic utility function is prevalently applied in the literature for designing PF schedulers [4]. In this paper, we adopt a similar assumption for the MAC scheduler. In steady-state conditions, UEs receive equal transmission probabilities, which results in each UE receiving an equal share of PRBs over time under the PF scheduler, see, e.g., [30]. B. Selecting Design Parameters ∆ and K We implement our approach in NS3 (v3.41), using the 5G-LENA module [31]. Each UE runs a modified udpserver application, which collects PRB utilization statistics and periodically sends this information to the ES every δ seconds. The feedback controller at the ES adjusts the send rates of udp-client applications according to Algorithm 1 every ∆ seconds, based on the feedback received from UEs. We expect that the speed at which the PRB utilization and send rate converge to their target values when the ES first starts transmitting to a UE is affected by the choice of feedback gain K and update interval ∆ (with δ = 50ms fixed). Fig. 3 shows simulation results demonstrating the transient following startup of a data flow vs. the choice of K and ∆. It can be seen from Fig. 3 (a) that as gain

100

75

75

50 K = 0.25 K = 0.5 K=1 K=2 K=5

25 0 0

2.5

5

7.5

10

Time (sec)

(a) Impact of K (∆ = 200ms)

PRB (%)

PRB (%)

100

B. Evaluation and Results

= 50ms = 100ms = 200ms = 500ms = 1000ms = 2000ms = 5000ms

50 25 0 0

5

10

15

20

Time (sec)

(b) Impact of ∆ (K = 1)

Fig. 3. Convergence rate vs. feedback gain K and update interval ∆. NS3 simulations, single UE, Pϵ = 95%, δ = 50ms, BW = 40MHz, MCS = 28.

K is increased (while ∆ = 200ms and δ = 50ms) the time to converge to the target PRB utilization (Pϵ = 95%) decreases. However, as the gain is increased the feedback loop eventually becomes unstable, e.g., the data for K = 5 which shows large, sustained oscillations. Similarly, it can be seen from Fig. 3 (b) that as the update interval ∆ is decreased the convergence time decreases. VII. Performance Evaluation A. 5G Testbed Our experimental testbed is a 5G standalone network based on the OpenAirInterface 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, including the RLC acknowledged mode (AM). We use the oai-ext-dn container of OAI as the ES, which runs on the same machine as the 5G core and BS. Each UE operates 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 synchronized via the PTP protocol using ptp4l program over a fiber optic LAN. Moreover, we use phc2sys program 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, see Fig. 1 (b). 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. We develop the server- and UE-side codes in Python for our prototype implementation of the rate allocation approach presented in Algorithm 1. The ES generates iPerf-like UDP traffic towards the UEs and inserts a sender-side 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.

We consider a downlink scenario with three UEs, each assigned an eMBB traffic flow: two UEs receive UDP RAPID flows, i.e., RAPID 1 and RAPID 2, and one UE receives a TCP Cubic flow. The UEs are placed in different locations, experiencing varying channel conditions. The key design parameter is the target PRB utilization. We set Pϵ = 0.9×106/3 ≈ 32 PRBs, corresponding to 30% PRB utilization for n = 3 UEs. The choice of a reduction factor of 0.9 is intended to enhance system reliability. This decision was based on observations of occasional peaks in OWD associated with high PRB utilization, typically around 95%, though such occurrences were rare. Through experimental evaluation, we determined that ∆ = 200ms, δ = 50ms, and K = 0.5 are proper values for our rate adaptation policy in Algorithm 1. These values are also consistent with the NS3 simulation results, see Fig. 3. We first initiate the TCP Cubic flow, and after a short interval, the RAPID flows start simultaneously. Fig. 4 (a) illustrates the goodput of the traffic flows. While the greedy Cubic flow achieves 20.4Mbps goodput, RAPID 1 and 2 also achieve consistently high goodput around 17.2Mbps and 14.8Mbps, respectively, which are 16% and 27% less than the Cubic flow. Note that these traffic flows experience different MCS indices over the downlink, see Fig. 4 (d). Furthermore, the convergence rate of the RAPID flows is fast, occurring within a few seconds after the flows begin, as highlighted in the zoomed inset in Fig. 4 (a). The reduced receive rate of the RAPID flows (compared with the Cubic flow) can be further analyzed in Fig. 4 (c), which depicts the PRB utilization over time. The TCP Cubic flow initially utilizes almost all 106 PRBs when there is no cross-traffic (/the RAPID flows). However, after the initialization of the RAPID flows, the PF scheduler at the BS limits the Cubic flow’s resource utilization to an average of 42 PRBs, while both RAPID flows, with Pϵ = 32, achieve an average of 32 PRBs, see Fig. 4 (c). The zoomed inset in Fig. 4 (c) showing the [20, 30]sec interval illustrates the quick convergence of RAPID flows to Pϵ . Despite the slightly higher goodput achieved by the TCP Cubic flow, the most significant difference is observed in the OWD measurements in Fig. 4 (b). The RAPID flows consistently maintain a much lower OWD compared to the Cubic flow. While the average OWD of the Cubic flow is 464.9 ± 33ms, RAPID 1 and 2 achieve OWDs below 23ms and 50ms (after removing the first second of the initialization phase), with averages of 6.5 ± 2ms and 8.5 ± 5ms, respectively. This represents a 72x and 55x reduction in OWD for RAPID 1 and 2, respectively, with significantly smaller fluctuations compared to TCP Cubic. The reduced fluctuation in OWD (and goodput) of the RAPID flows, compared to the TCP flow, is particularly important for applications such as XR, video streaming,

25

30

20 0 0

50

100

150

200

600

100

400 Cubic RAPID 1 RAPID 2

50

200 0 0

Time (sec)

0 20

25

50

100

20

Cubic RAPID 1 RAPID 2

25

30

50

30

150

200

Time (sec)

(a) Receive rate

30

60 40 20

(b) One-way delay

0 0

50

100

150

200

MCS Index (DL)

Cubic RAPID 1 RAPID 2

PRB

40

30 20 10 0 20

OWD (ms)

Goodput (Mbps)

60

20 10 0 0

Cubic RAPID 1 RAPID 2

50

Time (sec)

100

150

200

Time (sec)

(c) PRB utilization

(d) DL MCS

Fig. 4. Performance comparison of RAPID with TCP Cubic in a multi-UE scenario. The goodput in (a) is averaged over 200ms intervals. PRBmax,slot = 106, ∆ = 200ms, δ = 50ms, K = 0.5, and Pϵ = 30%. Experimental results.

and online gaming, which require stable performance, see Table 1 in [32]. Note that since the packet loss is very low, we did not include a packet loss plot. VIII. Discussion TCP Prague [33] is a recently developed L4S-compatible CC algorithm that also targets low delay, high data rate communication. The authors in [26] evaluate its performance in a single-UE scenario using a 5G OpenRAN testbed where they introduce multiple additional components for traffic control. These new functionalities may influence the performance of TCP Prague. Furthermore, [26] does not provide a detailed evaluation of TCP Prague. We are currently working on integrating L4S into our 5G testbed to enable a performance comparison between RAPID and TCP Prague in future work. The assumption about the PF scheduler in Section VI-A may not precisely reflect all schedulers implemented in proprietary BSs. Thus, our solution may face compatibility issues with certain types of schedulers, leading to under- or over-utilization of network resources. Therefore, designing control strategies that can adapt to such discrepancies and be more independent of the MAC scheduler is a significant challenge, and we plan to address this in future work. IX. Conclusions In this paper, we discussed the necessity of well-designed and well-configured transport layer solutions to realize high data rate and low latency communication over 5G edge networks. We showed that the QD at the RLC layer of the BS is correlated with the PRB utilization; therefore, adjusting the send rate to maintain a target PRB utilization can be applied to increase the end-toend performance, particularly the end-to-end delay. We then proposed a rate allocation policy for private 5G edge networks that regulates the downlink send rate based on PRB utilization feedback from UEs. We implemented the server- and UE-side codes on NS3 and in our 5G testbed to evaluate the performance of our design. The experimental results for a multi-UE scenario, where two RAPID flows coexist with one TCP Cubic flow, showed that RAPID flows achieved 72x and 55x lower OWD compared to TCP

Cubic, with negligible packet loss, at the cost of modest goodput reductions of 16% and 27%, respectively. These results further confirmed the feasibility and effectiveness of the proposed approach under real radio conditions. Acknowledgment This work was supported by the Distributed Artificial Intelligent Systems (DAIS) project under the Key Digital Technologies Joint Undertaking (KDT JU), Grant Agreement No. 101007273. References [1] D. G. Morin, P. Perez, and A. G. Armada, “Toward the Distributed Implementation of Immersive Augmented Reality Architectures on 5G Networks,” IEEE Communications Magazine, vol. 60, no. 2, pp. 46–52, 2022. [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] 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, Feb 2022. [4] 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, p. 307–319. [5] 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. [6] (2025) L4S. Accessed: May 10, 2026. [Online]. Available: https://www.nokia.com/bell-labs/research/l4s/ [7] 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, p. 58–66, Jan 2017. [8] J. Iyengar and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport,” RFC 9000, May 2021. [9] (2024) OpenFastPath. Accessed: May 10, 2026. [Online]. Available: https://openfastpath.org/ [10] (2016) ETSI Next Generation Protocols Group Releases First Specification. Accessed: May 10, 2026. [Online]. Available: https://www.etsi.org/newsroom/news/1135-2016-10-news-ets i-next-generation-protocols-group-releases-first-specification [11] 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. [12] D. Chefrour, “One-Way Delay Measurement From Traditional Networks to SDN: A Survey,” ACM Computing Surveys, vol. 54, no. 7, July 2021.

[13] H. Wan and K. Jamieson, “Evolving Mobile Cloud Gaming with 5G Standalone Network Telemetry,” 2024. [Online]. Available: https://arxiv.org/abs/2402.04454 [14] ETSI, “5G; System Architecture for the 5G System (5GS),” European Telecommunications Standards Institute (ETSI), Technical Specification (TS) 123.501 v17.5.0, July 2022. [15] L. S. Brakmo, S. W. O’Malley, and L. L. Peterson, “TCP Vegas: New Techniques for Congestion Detection and Avoidance,” in Proceedings of the Conference on Communications Architectures, Protocols and Applications (SIGCOMM), 1994, p. 24–35. [16] 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, p. 427–439. [17] 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. [18] 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. [19] 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, p. 64–74, July 2008. [20] N. Cardwell, Y. Cheng, K. Yang, D. Morley, S. Hassas Yeganeh, P. Jha, Y. Seung, V. Jacobson, I. Swett, B. Wu, and V. Vasiliev, “BBRv3: Algorithm Overview and Google’s Public Internet Deployment,” Presentation at IETF 119, 2024. [Online]. Available: https://datatracker.ietf.org/meeting/119/materials /slides-119-ccwg-bbrv3-overview-and-google-deployment-00 [21] Y. Im, P. Rahimzadeh, B. Shouse, S. Park, C. Joe-Wong, K. Lee, and S. Ha, “I Sent It: Where Does Slow Data Go to Wait?” in Proceedings of the 14th EuroSys Conference (EuroSys), 2019, pp. 1–15. [22] D. Zeynali, E. N. Weyulu, S. Fathalli, B. Chandrasekaran, and A. Feldmann, “Promises and Potential of BBRv3,” in Proceedings of the 25th International Conference on Passive and Active Measurement (PAM), 2024, p. 249–272. [23] 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, p. 413–425. [24] 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, p. 73–80. [25] ETSI, “MEC in 5G Networks,” European Telecommunications Standards Institute (ETSI), White Paper, June 2018. [26] 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. [27] Y. Huang, S. Li, Y. T. Hou, and W. Lou, “GPF: A GPUbased Design to Achieve 100 µs Scheduling for 5G NR,” in Proceedings of the 24th Annual International Conference on Mobile Computing and Networking (MobiCom), 2018, p. 207– 222. [28] F. Ronteix-Jacquet, “Reducing Latency and Jitter in 5G Radio Access Networks,” Ph.D. dissertation, Ecole nationale supérieure Mines-Télécom Atlantique, 2022. [29] OpenSim CTTC/CERCA, NR Module User Manual, 2024, release 3.3. [Online]. Available: https://cttc-lena.gitlab.io/nr/n rmodule.pdf [30] H. Yin, L. Zhang, and S. Roy, “Multiplexing URLLC Traffic Within eMBB Services in 5G NR: Fair Scheduling,” IEEE Transactions on Communications, vol. 69, no. 2, pp. 1080–1093, 2021. [31] N. Patriciello, S. Lagen, B. Bojovic, and L. Giupponi, “An E2E Simulator for 5G NR Networks,” Simulation Modelling Practice and Theory, vol. 96, p. 101933, 2019. [32] M. Gapeyenko, V. Petrov, S. Paris, A. Marcano, and K. I. Pedersen, “Standardization of Extended Reality (XR) over 5G

and 5G-Advanced 3GPP New Radio,” IEEE Network, vol. 37, no. 4, pp. 22–28, 2023. [33] K. D. Schepper, O. Tilmans, B. Briscoe, and V. Goel, “Prague Congestion Control,” Internet Engineering Task Force, InternetDraft, July 2024. [Online]. Available: https://datatracker.ietf.o rg/doc/draft-briscoe-iccrg-prague-congestion-control/04/

Related documents

• RAPID: Proactive Rate Control for Enabling High Data Rate and Low Latency in 5G Edge Networks#1298245
• One-Way Delay Model for 5G Low Latency, High Data Rate Communications#1298257
• One-Way Delay Model for 5G Low Latency, High Data Rate Communications#1291757
• Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service#500820
• Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP)#501357