PaperlayerView exact revision on arXiv

Source-linked AI summary

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.13749v1cs.NI

TL;DR

Next-generation applications need high data rates and low latency, while current transport congestion signals can fall short or be difficult to measure. RAPID controls send rates using target PRB utilization in private 5G edge networks; in a multi-UE testbed, its flows had much lower OWD than TCP Cubic with modest goodput reductions.

  • Problem

    Next-generation applications require high data rate, latency, and reliability, but existing transport approaches may not satisfy these requirements and OWD or RTT can be difficult or inaccurate congestion signals.

    Source: §I · p. 1

  • Method

    RAPID regulates downlink send rates to maintain target PRB utilization and avoid persistent BS queue backlogs in private 5G edge networks.

    Source: §I · p. 1

  • Results

    72x and 55x lower OWD with negligible packet loss, and 16% and 27% lower goodput, respectively, for two RAPID flows compared with TCP Cubic in a multi-UE testbed.

    Source: §I · p. 2

  • Takeaways & Limitations

    Maintaining target PRB utilization can increase end-to-end performance, particularly delay, in the evaluated 5G edge setting.

    Source: §IX · p. 6

    The assumed proportional-fair scheduler may not match proprietary BS schedulers, potentially causing under- or over-utilization of network resources.

    Source: §VIII · p. 6

Abstract

from arXiv · show

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 need high data rates and low latency, but existing transport congestion signals and deployment options have limitations. RAPID regulates send rates using target PRB utilization, and its testbed evaluation reports substantially lower one-way delay than TCP Cubic with modest goodput reductions.

  • Next-generation applications require high data rate, latency, and reliability, while existing 5G and Wi-Fi 6 networks and transport solutions may not meet those requirements.Source: §I · p. 1
  • Loss-based control reacts after queue overflow, while delay-based control faces OWD measurement challenges and RTT errors when the reverse path is queued.Source: §I · p. 1
  • Networkwide sniffing and ECN can gauge capacity or signal congestion, but deployment and upgrade requirements can make these alternatives impractical.ECN solutions such as L4S require updates to network infrastructure and end-user devices.Source: §I · p. 1
  • RAPID regulates downlink send rates to maintain target PRB utilization, aiming to avoid persistent BS queue backlogs while achieving high data rate and low latency.Source: §I · p. 1
  • 72x and 55x lower OWD, negligible packet loss, and 16% and 27% lower goodput, respectively, for two RAPID flows versus TCP Cubic in a multi-UE testbed.The testbed used OpenAirInterface and Ettus USRPs.Source: §I · p. 2

II. Related Work

Related congestion-control approaches use delay or loss signals, but each has limitations for low-latency wireless communication. BBR estimates bottleneck bandwidth using RTT and throughput, yet is not specifically designed for wireless networks.

  • Delay-based TCP Vegas and TCP BBR use RTT measurements to avoid queue buildup, but reverse-path queueing can undermine their performance in cellular networks,,,.Source: A. Congestion Control · p. 2
  • Loss-based TCP BIC and TCP Cubic increase send rates until packet loss, filling bottleneck queues and raising latency.Source: A. Congestion Control · p. 2
  • BBR estimates bottleneck bandwidth from RTT and throughput but is not designed specifically for wireless networks; studies report low-latency challenges, and initial work on BBRv3 raises performance concerns,,,,.Source: A. Congestion Control · p. 2

B. Congestion Control for LTE/5G Networks

Prior LTE/5G capacity-estimation methods use radio measurements, packet-reception patterns, or networkwide PRB observation, each with practical or accuracy constraints. RAPID's architecture places the bottleneck at the BS and manages downlink rate to limit RLC queue buildup while keeping the link utilized.

B. Congestion Control for LTE/5G Networks

  • Energy-based piStream estimates LTE bandwidth but is vulnerable to interference and needs fine-grained per-subcarrier information available only through radio monitoring software,.Source: B. Congestion Control for LTE/5G… · p. 2
  • CLAW estimates LTE cell-wide utilization from handset physical-layer information in around one RTT, but signal strength has limited predictive power and energy measurements can be error-prone,.Source: B. Congestion Control for LTE/5G… · p. 2
  • ExLL infers LTE bandwidth from short-window packet reception, but its end-to-end statistics can estimate available bandwidth inaccurately amid network dynamics.Source: B. Congestion Control for LTE/5G… · p. 2
  • PRB-based approaches, [13],, use passive sniffers to decode cell-wide control channels, but decoding is considered impractical and the approach has performance concerns.Source: B. Congestion Control for LTE/5G… · p. 2

III. System Architecture

  • The assumed edge architecture places the ES and UPF with the BS, treats the BS RLC layer as the bottleneck, and seeks to prevent persistent queue buildup while fully using link capacity.The current focus is downlink; uplink adaptation would have the ES update UE send rates before distributing them.Source: §III · pp. 2–3, Figure 1 · p. 3

A. Assumptions

The system model assumes a private 5G network with an edge server that administers traffic and can proxy connections to UEs. The data-flow model deploys the approach over UDP and assumes identical downlink traffic type and persistent RLC-buffer backlog at scheduling decisions.

1) System Model:

  • The private 5G system model places the ES near users, gives it centralized flow oversight, and allows it to act as a proxy gateway for traffic to and from UEs.Source: 1) System Model · p. 3

2) Data Flow:

  • The data-flow model uses UDP, assumes identical downlink traffic type carried in a single DRB per UE, and presumes packets are queued in each UE's RLC buffer at scheduling decisions.Source: 2) Data Flow · p. 3

IV. Latency Analysis

The analysis focuses on RLC queueing delay at the base station and relates it to PRB utilization. Simulations show how send rate, utilization, and delay change together, motivating operation near capacity to balance high data rate and low delay.

IV. Latency Analysis

  • Queueing delay at the BS’s RLC layer is the most significant, often overlooked component of one-way delay considered in the analysis.Other delay sources are excluded; queueing delay also depends on scheduling, other users’ queue occupancy, buffer sizes, and channel quality.Source: §IV · p. 3

V. Low Delay High Data Rate Operation

  • PRB utilization rises monotonically with send rate; with four equal-distance UEs, each UE’s maximum utilization is approximately 25%.The single-UE case can reach 100% utilization, while the four-UE case shares PRBs through the MAC scheduler.Source: §V · p. 3
  • As send rate approaches link capacity, one-way delay rises sharply alongside PRB utilization nearing its upper limit and the onset of packet loss.At lower send rates, delay increases more gradually.Source: §V · pp. 3–4
  • Paced packets accumulate at the RLC buffer until a transmission opportunity, and queueing delay tracks PRB utilization as the MAC scheduler allocates transmission resources.A backlog clears when a UE’s PRB requirement is below the available maximum; otherwise packets wait for later slots.Source: §V · p. 4
  • Operating near maximum achievable PRB utilization is proposed to retain high send rate with low delay, accepting a throughput cost for utilization below capacity.The observed trade-off is described as a relatively small data-rate reduction compared with the maximum possible.Source: §V · p. 4

VI. Controlling Delay

The controller adjusts the edge server’s downlink send rate using UE-reported PRB utilization to maintain a selected target. Its feedback rule increases or decreases the rate according to the difference between observed and target utilization.

VI. Controlling Delay

  • A feedback loop adjusts the edge server’s downlink send rate to maintain a selected target PRB utilization.The application’s QoS requirements can determine the target.Source: §VI · p. 4
  • UEs measure PRB utilization over intervals of duration δ and report it to the edge server via UDP; the server adjusts send rates over intervals of duration ∆, with ∆ > δ.The server uses the reports received within each ∆ interval.Source: §VI · p. 4
  • The controller increases send rate when average observed PRB utilization is below target and decreases it when utilization is above target.Feedback gain K balances convergence rate and stability.Source: §VI · p. 4

A. Selecting Design Parameter Pϵ

The target PRB utilization is selected per UE to reflect the number of active downlink flows. Equal sharing is motivated by the steady-state behavior of proportional-fair scheduling.

A. Selecting Design Parameter Pϵ

  • For m RAPID flows with identical QoS requirements, the paper assigns a shared target PRB utilization; targets can be adjusted per UE when QoS requirements differ.For full-load analysis, the target is set to PRBmax,slot/n, where n is the total number of active downlink flows.Source: A. Selecting Design Parameter Pϵ · p. 4
  • Dividing PRBmax,slot by n assumes equal PRB allocation, reflecting proportional-fair schedulers’ steady-state equal transmission probabilities and equal PRB shares over time.The paper notes that some proprietary schedulers may use more sophisticated policies.Source: A. Selecting Design Parameter Pϵ · p. 4

B. Selecting Design Parameters ∆and K

The feedback gain K and update interval ∆ affect how quickly the controller reaches its target PRB utilization. Simulations show faster convergence with larger K or shorter ∆, but sufficiently large gain can destabilize the feedback loop.

B. Selecting Design Parameters ∆and K

VII. Performance Evaluation

The evaluation uses an OpenAirInterface-based 5G standalone testbed and synchronized server and UE systems to implement RAPID and measure one-way delay.

A. 5G Testbed

  • The standalone testbed uses OpenAirInterface for the core, base station, and UEs, with n78 TDD, 40 MHz bandwidth, 106 PRBs per slot, and 30 kHz subcarrier spacing.It uses single-layer transmission, 0.5 ms slots, and the default OAI RLC acknowledged mode.Source: A. 5G Testbed · p. 5
  • The edge server and base station share a machine, while each UE runs on a separate, hardware-matched machine.PTP synchronizes the Ethernet NICs over fiber, and phc2sys synchronizes system clocks to the PTP hardware clock.Source: A. 5G Testbed · p. 5
  • A USRP X310 at the base station communicates with UE-side USRP B210 radios, all synchronized to an OctoClock reference.The radios use the UHD 4.6 driver.Source: A. 5G Testbed · p. 5
  • The Python prototype sends timestamped UDP traffic from the edge server, using synchronized clocks to measure one-way delay at each UE.The implementation follows the rate-allocation approach in Algorithm 1.Source: A. 5G Testbed · p. 5

B. Evaluation and Results

In a three-UE downlink test, two RAPID flows share the base station with TCP Cubic. RAPID substantially lowers one-way delay while giving up some goodput.

B. Evaluation and Results

  • The test uses two RAPID UDP flows and one TCP Cubic flow on three downlink UEs experiencing different channel conditions.Source: B. Evaluation and Results · p. 5
  • The target is about 32 PRBs, or 30% utilization, using a 0.9 reduction factor intended to improve reliability.The policy uses Δ = 200 ms, δ = 50 ms, and K = 0.5; the factor accounts for rare OWD peaks near 95% utilization.Source: B. Evaluation and Results · p. 5
  • RAPID 1 and 2 achieve 17.2 Mbps and 14.8 Mbps goodput, 16% and 27% below TCP Cubic's 20.4 Mbps.The flows converge within a few seconds; after RAPID starts, the PF scheduler allocates an average of 32 PRBs to each RAPID flow and 42 PRBs to Cubic.Source: B. Evaluation and Results · p. 5, Figure 4 · p. 6
  • 72x and 55x lower OWD than TCP Cubic, with averages of 6.5 ± 2 ms and 8.5 ± 5 ms versus 464.9 ± 33 ms, respectively.The RAPID averages exclude the first second of initialization; the flows also had significantly smaller OWD fluctuations.Source: B. Evaluation and Results · p. 5, Figure 4 · p. 6
  • Packet loss is reported as very low, and no packet-loss plot is included.Source: B. Evaluation and Results · p. 6

VIII. Discussion

The discussion identifies compatibility with proprietary base-station schedulers as an open challenge. The conclusion reports large OWD reductions with modest goodput costs and negligible packet loss in the tested multi-UE scenario.

VIII. Discussion

  • A direct RAPID–TCP Prague comparison remains future work; the cited TCP Prague evaluation used a single-UE Open-RAN testbed with additional traffic-control components.Source: §VIII · p. 6
  • Proprietary base-station schedulers may diverge from the PF assumption, risking resource under- or over-utilization.Source: §VIII · p. 6

IX. Conclusions

  • 72x and 55x lower OWD than TCP Cubic, with negligible packet loss and goodput reductions of 16% and 27%, respectively, in the multi-UE test.Source: §IX · p. 6
  • The proposed policy regulates downlink send rate using UE PRB-utilization feedback, based on the reported correlation between base-station RLC queueing delay and PRB utilization.Source: §IX · p. 6
Loading 2610.13749v1…