Choir: Tackling RTBC Performance Impossible Triangle with 5G Collaboration Wenji Du1,2 , Wanghong Yang2 , Baosen Zhao1,2 , Yongmao Ren2 , Xu Zhou2 , Jiaxing Zhang1,3 , Tingting Yuan4 , Qinghua Wu3 , Xiaoming Fu4 , Gaogang Xie1,2 1 University of Chinese Academy of Sciences, China
2 Computer Network Information Center, CAS, China
3 Institute of Computing Technology, CAS, China
arXiv:2605.02510v1 [cs.NI] 4 May 2026
Abstract Real-time Broadband Communication (RTBC) scenarios, such as cloud virtual reality and 8K live streaming, further raise the criteria of the Performance Triangle, including video bitrates exceeding 30Mbps, tail delay below 50ms, and fairness guarantees for multi-user concurrent access. Based on our testing and analysis, existing RTBC-oriented rate control solutions, including end-to-end algorithms and networkassisted algorithms, fail to simultaneously satisfy all performance metrics. The native dynamic delay and physical layer resource allocation strategy inherent to 5G radio access network (RAN) are the key reasons. These solutions lack adaptation to the 5G architecture, leading to reduced decision performance. This paper proposes Choir, an innovative collaborative solution mainly deployed on 5G base stations that deeply integrates 5G radio characteristics and video streaming traffic patterns to guide sender-side efficient rate control. Extensive simulation and testbed evaluations demonstrate Choir’s significant performance on high average bitrate, low tail delay and inter-flow fairness over different 5G network scenarios.
1
Introduction
Compared to real-time communication (RTC) scenarios primarily pursuing low latency, real-time broadband communication (RTBC) scenarios require the simultaneous satisfaction of the Performance Triangle defined as ultra-low latency, ultrahigh throughput, and fairness. Taking cloud virtual reality in densely populated entertainment spaces as an example, delivering an immersive user experience requires latency below 50 ms and a bitrate of at least 30 Mbps. The fairness issue also becomes increasingly prominent. Users urgently demand stable transmission unaffected by concurrent users within the same access network [1–6]. With broad bandwidth and robust mobility support, 5G radio access networks (RAN) serve as a critical foundation for RTBC services. As shown in Fig. 1, RTBC servers can be deployed near the core data processing unit, User Plane Function (UPF), in 5G networks, ensuring that the basic link propagation delays with the user equipment (UE) does not exceed 20ms [7]. Researchers have proposed numerous rate control solutions for low-latency video streaming transmission [8–15]. These solutions typically evaluate network states via end-side active
4 University of Göttingen, Germany Core
Server
UPF
RAN
Edge
Base Station
UE
< '&. /&. 1 !"2 455
789%
Figure 1: Transmission scenario of RTBC services in 5G probing or network nodes feedback, then design video bitrate and sending rate control algorithms to rapidly respond to network fluctuations, preventing network congestion and latency spikes. However, these rate control solutions fail to meet RTBC user requirements in 5G networks, even though some algorithms demonstrate good performance in Ethernet and Wi-Fi. The underlying architecture of 5G RAN is the root cause. Even without packet loss, the Time Division Duplex (TDD) pattern at the physical layer inherently subjects packets to dynamic transmission delays due to alternating uplink/downlink transmission periods. When the radio channel’s Block Error Rate (BLER) increases, retransmissions —from the Hybrid Automatic Repeat reQuest (HARQ) mechanism at the Media Access Control (MAC) layer to the Acknowledged Mode (AM) at the Radio Link Control (RLC) layer—introduce additional latency up to tens of milliseconds. These RAN-induced dynamic delays force existing rate control solutions into persistent oscillation, failing to fully utilize RAN capacity while struggling to achieve stable low latency, which is unacceptable for RTBC users. Conversely, 5G RAN’s per-flow dedicated queues and priority-aware scheduling inherently guarantee physical-layer resource fairness. By enabling rate control solutions to rapidly adapt to dynamic resource allocations, this architecture maybe tackle the Performance Triangle: simultaneously maximizing bandwidth utilization, minimizing queuing delay, and ensuring inter-flow fairness. We propose Choir, a comprehensive bandwidth prediction and rate control solution that jointly accounts for 5G RAN’s dynamic resource allocation mechanisms and video traffic characteristics, guides sender-side bitrate and pacing rate adaptation, thereby achieving optimal bitrate-delay perfor-
mance across diverse channel conditions while guaranteeing fairness among concurrent flows. We implemented and evaluated Choir with several stateof-the-art (SOTA) rate control solutions on our 5G module simulation and open-source 5G platform. Experimental results show that Choir reduces tail latency by 68.64% to 90.7% in various 5G network scenarios. In summary, our key contributions in this paper are: • We tested and analyzed the performance of existing SOTA RTC rate control solutions in 5G RAN network, with fine-grained delay breakdown. • We proposed Choir, an innovative collaborative solution that enable base stations to perform accurate guidance bandwidth prediction which dynamically mapped from physical-layer resource allocations with incorporating video traffic characteristics, and synchronizing the guidance bandwidth with end-side rate control algorithms timely. • We deployed and extensively evaluated Choir in tracedriven simulation and open-source 5G testbed, demonstrating its superior performance to achieve the Performance Triangle.
2
Background and Motivation
2.1 Tradeoff Strategy of Existing RTBC Solutions Existing solutions aim to achieve the Performance Triangle but often have to make tradeoff decisions among the three metrics. Latency, especially tail latency, is prioritized since long tail latency causes playback stalls that rapidly degrade user retention. Bitrate ranks second, as it directly impacts visual quality; for immersive devices like VR, reduced quality triggers user motion sickness. Regarding fairness, heterogeneous flows (e.g., BBR [16] competing with Cubic [17]) struggle to achieve stable fairness due to conflicting algorithmic goals. Thus, fairness is typically a secondary consideration after ensuring latency and bitrate performance, and it is frequently compromised. Even if prioritizing low latency and high bitrate without strict fairness requirements, solutions still face two challenges: accurate network state estimation and timely response to network dynamics. These challenges have spurred numerous ideas, generally categorized into two types: end-side active probing or network-assisted feedback. As shown in Fig. 2, these solutions fundamentally operate at the sender side, integrating bitrate and framerate control mechanisms for video encoders with congestion control algorithms (CCAs) in pacing controller.
Video Encoder
Congestion Controller
Base Station
pkt by pkt
frame by frame queue length
Video Decoder
slot by slot queue length
queue length
frame i frame i+1 time
time
time
Figure 2: The transmission procedure of video stream in 5G.
End-side solutions primarily infer network metric changes through data packet and returned ACK transmission states. Examples include: SCReAM [8], COPA [9] and SQP [10] are window-based, which rely on packet trains signals; Pudica [11] sends probing packets to measure bandwidth utilization; PBE-CC [18] extracts and feeds back wireless channel states at the receiver. Network-assisted solutions leverage network nodes to explicitly report bottleneck capacity and congestion. Explicit Congestion Notification (ECN) [19], ABC [12], and L4S [13, 20, 21] signal congestion via in-band packet header markings. Their feedback signals must be processed at the receiver, which would be lagged by a longer feedback loop during congestion. Zhuge [14] implicitly notifies senders via delayed ACKs, its access-point-assisted method (e.g., direct uplink scheduling control) saves congestion signal propagation delays; Recent RTC proposal SCONE [15] proactively feed back bottleneck bandwidth and queueing length for video streams. Since most RTC solutions take delay as a key congestion signal, accurately detecting true network states becomes increasingly challenging in 5G RANs characterized by delay fluctuations. Our experiment results, as shown in Fig. 3, indicate that most solutions (COPA, Pudica, SQP, SCReAM, SCONE) exhibit unstable transmission rates and persistent delay oscillations in even stable 5G RAN environments; furthermore, abrupt bandwidth reductions exacerbate sustained queue accumulation and elevated tail latency. Although ABC and L4S exhibit quick adaptation to bandwidth reduction, they require a long convergence time and continue to experience rate fluctuations even after convergence.
2.2 Challenges Raised by 5G RAN: Native Dynamic Delay The inherent design of 5G RAN at the physical, MAC, and RLC layers introduces native dynamic latency, fundamentally hindering stable convergence for SOTA solutions targeting low latency. Physical Layer Dynamics: 5G RAN configures radio subframes with TDD patterns, dividing physical channels into alternating downlink (D) and uplink (U) periods. For ex-
BandWidth COPA SCReAM+L4S Pudica SQP SCReAM ABC SCONE Choir
Bitrate (Mbps)
80 60 40 20 0
0
2
6 Timeline (s)
8
COPA SCReAM+L4S Pudica SQP SCReAM ABC SCONE Choir
102
101
10
(a) Bitrate
103
Frame Delay (ms)
4
0
2
4
6 Timeline (s)
8
10
(b) Frame delay
Figure 3: Performance of different solutions in 5G networks. ample, the widely adopted DDDSU pattern (designed for heavy downlink traffic) allocates downlink-to-uplink slots in a 3.5:1.5 ratio. Data packets arriving in the downlink queue during uplink slots may incur additional queuing delays (e.g., 1.5 ms). Consequently, even in stable networks, packets of identical sizes experience variable transmission delays depending on their arrival timing. Retransmission-Induced Latency: To mask packet loss from upper layers and senders, 5G implements retransmission mechanisms at both MAC and RLC layers, given its high channel BLER ( 10% in our tests). • MAC Layer: First HARQ retransmission introduces 6 ms of latency, accumulating to 16 ms after three retransmissions. • RLC Layer: In RLC AM, retransmitted packets re-enter the RLC buffer queue, where delays depend on queue length and may exceed tens of milliseconds. While this design aims to prevent sender-side rate reduction triggered by perceived packet loss, it inadvertently amplifies tail latency in practice. RTBC video streams are disproportionately affected by retransmission mechanisms. Even when transmitted over unreliable protocols like UDP, subsequent frames experience
cascading queuing delays during RAN channel fluctuations, as underlying retransmissions of prior frames occupy shared buffer resources, leading to multi-frame latency escalation. Traditional solutions, such as congestion ratio signaling or end-side probing, prove insufficient to promptly and accurately diagnose the root causes of latency spikes in 5G RAN. Only solutions like SCONE, which directly reports base station statuss including available bandwidth and queue length, achieve relatively stable performance.
2.3 Opportunity Provided by 5G RAN: Native Resource Fairness However, the 5G RAN architecture also provides physical foundation for the realization of the Performance Triangle. In Wi-Fi and wired networks, routers typically manage multiple same-priority flows within a single queue, leading to inevitable inter-flow competition. A single flow’s excessive data volume can degrade transmission latency for all co-existing flows, triggering network-wide congestion. In contrast, 5G RAN implements per-flow dedicated queues and a polling-based scheduling mechanism for same-priority multi-flow scenarios, achieving physical resource fairness. Consequently, each flow’s rate control mechanism neither requires nor can monopolize other users’ physical bandwidth. This aligns with the Congestion Control Algorithm Independence (CCAI) principle proposed by [22], where CCAs are theoretically relieved from enforcing fairness, thereby focusing solely on achieving bandwidth-delay joint optimization. However, unlike persistent flows, the intermittent transmission of video frames causes queues of multiple video streams within the same base station to rapidly toggle between active and inactive states, resulting in more frequent resource allocation fluctuations. To prevent queue buildup and prolonged delay, sender-side reactions must synchronize with physical-layer capacity allocation at ultra-low latency. Existing solutions fail to adapt to such rapid resource dynamics. Moreover, divergent response logics across solutions further exacerbate throughput imbalance among concurrent flows. Under these conditions, the target of rate control solutions shift toward minimizing latency while elastically utilizing base station-allocated capacity, thereby satisfying RTBC users’ dual Quality-of-Experience (QoE) demands for high bitrates and low latency. We propose assigning both network dynamics estimation and traffic pattern-aware rate adaptation to the base station. This architectural shift enables RTBC senders within the same RAN to achieve max-min fair resource utilization across concurrent flows through minimal communication overhead, realizing the latency-minimal transmission at higher bitrates. To achieve this vision, we design a base station-collaborated
Client
Congestion Controller
t
k
p
a
t
a
D t
k
p
a
t
Edge Header
QUIC Transport
Pacing Rate
Target Bitrate
a
Frame Sender
D
Frame Encoder
QUIC Transport
Server
RAN ACK
ACK Available Bandwidth
CQI
Encoder RTP QUIC
header GTP-U
UDP/IP L2/L1
UDP/IP
UPF
L2/L1
Payload
L2/L1
AN layer
Frame Decoder
Decoder RTP QUIC
GTP-U UDP/IP
Frame Receiver
Base Station
MCS
TBS
RLC Buffer
PRB
UDP/IP AN layer
Figure 4: The Framework of Choir rate control framework specifically for 5G RAN’s unique concurrency and channel dynamics, Choir.
3
Choir Design
3.1
Overview
The overall framework of Choir is shown in Fig. 4. To achieve the Performance Triangle goals for RTBC video streaming in 5G networks, Choir must precisely capture the dynamics of 5G RAN and video stream characteristics for accurate rate control. Choir implements two key functions at the base station. First, it estimates the allocated bandwidth for each queue in the next scheduling period using underlying channel information. Second, it predicts queue length trends by analyzing video stream patterns, calculates draining rates targeting zero queuing, derives available bandwidth, and delivers this guidance value to senders via uplink ACK headers. Additionally, since existing sender congestion controllers cannot recognize or utilize the guidance bandwidth, Choir deploys a lightweight, QoE-oriented rate control algorithm on the sender side. This algorithm converts guidance bandwidth into target bitrate and pacing rate.
3.2 Radio characteristics oriented capacity estimation This module ensures precise mapping from physical resource allocation to actual allocated bandwidth for each flow’s queue at base station. Challenge 1: To accurately capture highly dynamic resource allocation, bandwidth prediction must operate at the
granularity of the minimum scheduling period. In mobile networks, multiple flows with the same priority frequently transition between active and inactive states, forcing the base station to perform high-frequency resource reallocation. Thus, the base station first evaluates resource allocation for each user in the next transmission slot, which is generally 0.5ms or 1ms in 5G RAN. At the beginning of each connection, this module calculates the number of available physical resource blocks (PRBs) to each flow i based on the current number of concurrent active flows Nactive . PRBi =
PRBRAN Nactive
(1)
where PRBRAN represents the total number of PRBs of the current base station. PRBi represents the number of PRBs that flow i can use per transmission time interval (TTI) of the base station. This value stabilizes when the number of concurrent active flows remains constant. For a new TTI, base station need to update PRBi according to the idle resource in the last TTI. We then define PRBused as the total number of PRBs allocated by the base station to all active users and uPRBi as the number of used PRBs of active flow i in the last TTI. PRBused should not exceed PRBRAN . Thus, PRBi = max(uPRBi +
PRBRAN − PRBused PRBRAN , ) (2) Nactive Ntotal
The base station derives the modulation and coding scheme (MCS) value based on the channel quality indicator (CQI) reported by the UE to determine the bit rate per symbol. Meanwhile, the scheduling algorithm considers the current network load to allocate resources, especially the transport block size
(TBS) per TTI, to optimize network performance. Thus, the physical layer transmission rate PRi per PRB for the current flow i in bytes/ms is given by: T BSi DN PRi = · (3) T T I · PRBi T N where T BSi represents the number of bytes sent by flow i in 1 TTI at the physical layer of the base station. The uplink period length (UL) and downlink period length (DL) are determined by the radio frame structure of 5G base station. We calculate relevant parameters by measuring the total number of TTI (T N) and the total number of downlink TTI (DN) over a 100ms period. It is important to note that not all downlink TTI are used for transmitting user data; some may be allocated for control signaling and other purposes. Therefore, when counting DN, we only consider those actually used for user data transmission, ensuring that the measurements more accurately reflect the downlink capacity. Therefore, the theoretical maximum physical capacity Ci for flow i in the next TTI can be determined as: Ci = PRBi · PRi
(4)
Challenge 2: Mapping physical layer capacity to transport layer bandwidth requires accounting for MAC and RLC layer retransmissions that occupy additional bandwidth. We define RReT x represents the retransmission rate. On a shorter timescale, the RReT x can be calculated as the number of HARQ (HN) to the total downlink TTI (DN) over a given period. To improve accuracy, this module selects 10ms as the shortterm statistical period. Compared to the physical layer parameter block error rate (BLER), which is statistically updated only every 100 ms, RReT x provides higher temporal granularity. HN RReT x = (5) DN Thus, this module can calculate the allocated bandwidth for flow i in the next TTI, denoted as BWi : Ci · γ BWi = (6) 1 + RReT x where γ represents the proportion of effective data in a physical layer transport block after removing the overhead. Since the data size of each transport block varies, the overheader ratio also differs. Therefore, this proportion is calculated by averaging the data across all transport blocks within a 10ms window.
3.3 Flow pattern oriented available bandwidth prediction This module integrates video stream transmission dynamics to map allocated bandwidth BWi into near-zero queue guidance di for the sender. bandwidth BW
In pursuit of low latency, the general formulation for guiddi can be expressed as: ance bandwidth BW di = (η × BWi − DRi )+ BW
(7)
η is a constant less than 1, set to 0.95 here. DRi is the required draining rate to provide empty queue before new video frame comes. The goal is to utilize 95% of the available bandwidth, reserving some capacity to achieve lower latency. y+ represents the positive operator, meaning that if the rate required to drain the queue at the base station exceeds the allocated bandwidth, the feedback estimated available bandwidth value to the sender is set to 0.The base station attaches this rate value to the ACK packet header and transmits the information back to the sender. Challenge 3: Despite lacking prior knowledge of the flow’s actual frame size and frame interval, the base station must accurately estimate both the total data volume entering its queues before the sender updates the bitrate and the available queue drainage time, thus deriving a draining rate capable of timely queue clearance. Given: PredQi DRi = (8) FIi where PredQi is the estimated queue length, FIi is the estimated frame interval. We estimate frame interval FIi firstly. Video frames are generated periodically (e.g., 16.6 ms intervals for 60 fps streams), while packets within the same frame exhibit minimal interpacket intervals. Leveraging this property, two consecutively enqueued packets are classified into distinct frames if their inter-packet interval exceeds a predefined threshold. By identifying the tail packet timestamp of frame n and the head packet timestamp of frame n + 1, alongside the head packet timestamp of frame n, the frame interval can be calculated. To enhance prediction accuracy, we apply an Exponential Weighted Moving Average (EWMA) to historical and current frame interval values. FIi = α · FIn−1 + (1 − α) · FIn
(9)
where the weight α is 0.8. Next, we predict enqueued and dequeued data volumes based on the propagation delay between the base station and the sender. The dequeued data volume is calculated based on the average allocated bandwidth per frame interval BWi . Converting the frame interval FIi into the number of TTIs yields N
BWi =
TTI BWi ∑ j=1 NT T I
(10)
The enqueued data volume is calculated as the sum of downlink in-flight data frames and newly generated data frames during feedback uplink transmissions.
The number of all in-flight data frames and newly generated data frames is: FNumi = ⌊
2 ×WiredNDi ⌋+1 FIi
(11)
The wired network delay WiredNDi of flow i is measured using ping between the base station and the server. Ti = (T T I + FIi · FNumi )
(12)
Ti represents the time between the timestamp that current feedback reaches the sender and the timestamp that newly generated frame arrive at the base station. This time is estimated based on all frames that were sent before the next bitrate update but have not yet arrived at the base station, also includes a TTI of one base station scheduling period. LowerTi = NowT − FIi · (FNumi − 1) − 2 ·WiredNDi (13)
queue length within the time window, this approach effectively mitigates false peak interference caused by bursty traffic while accurately capturing the lower bound of the channel’s carrying capacity. Algorithm 1: Flow Pattern-Oriented Available Bandwidth Prediction Data: FIn−1 , FIn , α, BWi , NT T I , WiredNDi , T T I, NowT , HisBWk , êk , rlcQi , η di Result: BW 1 2
function Available Bandwidth Prediction(): FIi ← α · FIn−1 + (1 − α) · FIn ; N
3 4
10
Ti ← T T I + FIi · FNumi ; t BWn ← ∑Ni=1 BWni ; PredQi ← ∑FNum k=1 (HisBWk − êk ) × FIi + rlcQi − BWi × Ti ; i DRi ← PredQ FIi ; di ← η × BWi − DRi + ; BW di return BW
3.4
User experience oriented rate control
5 6
U pperTi = NowT − FIi · FNumi − 2 ·WiredNDi
(14)
LowerTi and U pperTi represent the lower and upper bounds of the calculated delay interval, respectively, while NowT denotes the current time when the base station executes the algorithm. Using this delay interval, the most recently recorded feedback ACK at the base station can be retrieved, along with its corresponding feedback rate HisBWk . Finally, we successfully capture the new base station queue length PredQi of flow i during the decision-to-execution latency between the base station and sender. FNum
PredQi = ∑ (HisBWk − êk ) × FIi + rlcQi − BWi × Ti (15) k=1
êk : An error correction term for HisBWk is derived from autoregressive statistical analysis of discrepancies between the historically predicted bitrate and the actual transmitted bitrate. rlcQi : The base station system uses TTI as the smallest time granularity, and the queue length of the RLC layer buffer for user equipment n is sampled in real time during each TTI. To effectively characterize the actual utilization efficiency of channel resources, we employ a sliding time window-based minimum queue statistic, denoted as RLCn . This metric is defined as the minimum queue length among all sampled instances within the most recent frame interval. This design of rlcQi is motivated by an in-depth analysis of the bursty transmission characteristics of video streaming. Traditional methods, such as moving averages or instantaneous queue indicators, suffer from inherent limitations. The former, due to its smoothing effect, fails to promptly capture bursty load variations, while the latter is susceptible to transient arrival fluctuations that may introduce noise into the information retrieval process. By extracting the minimum
T T I BW ∑ j=1 i ; Nj TTI k i FNumi ← 2×WiredND + 1 ; FIi
BWi ←
7
8 9
This module translates the base station’s guidance bandwidth di into two executable parameters: a target bitrate for the BW sender encoder and a pacing rate for the congestion controller, preventing sender-side queue buildup. It further supports bitrate adaptation based on user-specific experience requirements. Impact of bitrate dynamics in the encoder. There are performance differences between various encoders. Standard encoders may take 2-3 frames to adjust from the current bitrate to the target bitrate, with each adjustment having a small bitrate gradient. However, high-performance encoders can immediately reach the target bitrate within a single frame, which can cause frequent fluctuations in actual bitrate under Choir’s mode. Based on the available bandwidth feedback from the base station, the sender calculates and reports the target bitrate to the encoder to ensure that the bitrate adapts to the available bandwidth. Additionally, it is necessary to ensure that the pacing rate of the sender buffer is sufficiently larger than the actual bitrate to avoid packet queuing at the sender. d returned by the base The sender can directly use the BW station as the target bitrate passed to the encoder to achieve the lowest network transmission delay. d , which takes into account the base However, since the BW station’s queue draining rate, can fluctuate significantly, adjusting the encoder’s bitrate in real-time based on this value
may lead to visual quality fluctuations that could affect the user experience. Therefore, the sender can smooth this value over a period of time. This module introduces a smoothing coefficient ε, which is currently set to 1, meaning that the target bitrate BRi d directly. adopts current allocated bandwidth BW ε set to 10 means that the historical value of the target bitrate assigned to the encoder for the last 9 times and the d will be smoothed. current BW Thus, the target bitrate BRi to be reported to the encoder at decision moment is given by: BRi =
d ∑ε−1 i=1 ·HisBRn + BWi ε
Figure 5: Open-source 5G network testbed Table 1: RAN Configuration
(16)
Parameters Bandwidth Frequency TDD Pattern Sub-Carrier Space
where HisBRn represents the historical bitrate record of each frame n generated by the sender’s encoder. And the pacing rate of congestion controller is: PRi = ρ · max(ReceiveRate, BRi )
(17)
The sender calculates the receiving rate based on the acknowledged byte count from ACK packets and selects the maximum receiving rate (ReceiveRate) over a past time window as a reference. The pacing rate must be greater than both ReceiveRate and the upcoming bitrate assignment BRi . To ensure this, we set the scaling factor ρ empirically to 1.25 in our experiments. By employing a variable pacing rate, we ensure that the sender’s transmission rate remains sufficient, while preventing the send buffer from becoming the primary bottleneck that increases latency. This approach shifts congestion primarily to the wireless link bottleneck, allowing more effective bandwidth adaptation.
4
Implementation
We first configured a simulation environment to import highly fluctuating traces for single-stream performance testing. A RAN testbed with a capacity of 30Mbps was used to validate simulation results. We deployed a RAN testbed with a capacity of around 300Mbps to support concurrent experiments with multiple high-bitrate streams.
4.1
Trace-driven 5G Module Simulation
Considering 5G emulation limitations on Mahimahi [23], we adopt the 5G LENA module of the NS3 to explicitly configure TDD patterns, achieving realistic dynamic delay [24, 25]. The 5G LENA is a new radio (NR) network module and incorporates physical layer, Medium Access Control (MAC) layer, and RLC layer features aligned with NR Release 15 TS 38.300 [26]. Considering the potential variability of wired network latency between senders and 5G base stations in real-world
in B210 in openXG 40 MHz 100 MHz 3.5 GHz DDDSU 30 KHz
scenarios, we set sender-to-base station latency to 1ms, 10ms, and 20ms in simulations to observe performance of different solutions across conditions.
4.2
Software-defined 5G Open-RAN Testbed
As shown in Figure 5, we establish two base station systems with different capacities. The upper system uses a host equipped with the open-source OAI 5G NR protocol stack [27] and a USRP B210 as the radio frequency board. The bottom system integrates the OAI 5G NR protocol stack with the high-performance radio frequency board of the Witcomm OpenXG [28]. The basic framework of the deployed OAI 5G NR protocol stack complies with the requirements of 3GPP R15, with upgrades referencing key features from 3GPP R16 and R17, including the Radio Resource Control (RRC) protocol and the Radio Link Control (RLC) protocol [29–31]. Both systems support the Hybrid Automatic Repeat reQuest (HARQ) mechanism at the MAC layer and the Acknowledgement Mode (AM) retransmission mechanism at the RLC layer [32]. In our network topology, the open-source core network free5GC is deployed on a standalone server, with the core network and applications isolated using Docker. These components are connected to both base stations via wired links, with a physical bandwidth of 1Gbps. We use a combination of Customer-Premises Equipment (CPE) and laptops as receiver to facilitate more concurrent streams and data collection. The OAI 5G UE protocol is deployed on the laptops.
4.3
Upper Layer Protocols
The QUIC is deployed as the transport layer protocol for both simulation and testbed. We adopt the Ali XQUIC, which supports datagram mode transmission [33]. For the application layer, we refer to the draft specification of RTP over QUIC for custom development in this environment [34]. In terms of congestion control mechanisms, the RTCP feedback is removed, and instead, XQUIC’s ACK feedback is used to provide network status information to the sender. The transport layer’s Congestion Control Algorithm (CCA) is responsible for adjusting the pacing rate or congestion window. Additionally, the gstreamer encoder, which supports H.264, is integrated with XQUIC for inter-process communication.
4.4
Feedback to Sender
To reduce feedback latency and enhance the efficiency and timeliness of feedback information, this approach adopts an online feedback mechanism. The base station directly marks feedback information within uplink data packets, thereby shortening the feedback path. Given the complexity of QUIC’s encrypted payload mechanism, Choir utilizes the IP option field to carry base station feedback information. Specifically, a new field is designed within the IP option to encapsulate the feedback rate information from the base station. The implementation must support encoding both the rate value and the corresponding unit length within the option field. [35].
5
Evaluation
5.1
Experiment Setup
First, all encoded video streams have a fixed frame rate of 60FPS, so the theoretical video frame interval is 16.6ms. Baselines. The baselines include both end-side solutions and network-assisted solutions. For end-side solutions, we deploy: • Pudica [11]: A flow control solution that precisely controls delay using bandwidth utilization rate, integrated with XQUIC. • SQP [10]: A delay-based congestion control algorithm that probes bandwidth using precise sending control of each frame, integrated with XQUIC. • SCReAM [8]: A widely used delay-based rate control algorithm. • COPA [9]: A delay-based congestion control algorithm designed for wireless networks, implemented with δ = 0.1.
Here, we did not include additional comparisons with more bitrate control algorithms such as GCC [36], and NADA [37], as previous research shows SCReAM has better latency performance compare to GCC and NADA [38]. For network-assisted solutions, we deploy: • L4S [13]: A feedback-driven collaboration solution where the base station predicts congestion variations by sensing queueing delay thresholds and informs the sender of "increase" or "decrease" bandwidth signals through the receiver. • ABC [12]: A solution where network devices such as access points actively provide "acceleration" and "deceleration" signals by accurately predicting the forwarding bandwidth. • SCONE [15]: A collaboration solution where the base station informs the sender of bandwidth capacity and queue length, implemented with draining time as 16.6ms. PBE-CC is excluded from the baseline since it only implements bandwidth feedback without addressing queueing impacts for video streams. Theoretically, even with queue drainage function, PBE-CC underperforms SCONE due to delayed feedback from receiver-side. Traces. The simulation environment evaluation was conducted using traces collected from real 5G dynamic network. Metrics. We use the following metrics for evaluation. • Frame delay. The time between frame encoding and decoding, reflecting real-time latency performance. We measure average delay, 95th percentile tail delay, and 99.9th percentile tail ldelay. • Average Bitrate. The common indicator of video quality, with larger rate indicating higher visual fidelity.
5.2
Performance of single flow transmission
We varied the wired network latency between the sender and the base station to investigate the impact of different latency on algorithm effectiveness. As shown in Fig. 6, Choir outperforms other solutions in the frame delay and the average bitrate. With increasing wired network latency, both end-side solutions and network-assisted solutions suffer from delayed network state reactions, leading to uncontrollable increases in frame tail delay or decreases in average bitrate. For 99.9th percentile tail delay: Under 1 ms wired network latency, while SCONE achieves 4.9% lower tail latency than Choir, Choir still reduces latency by 45.5% to 90.7% compared to other solutions. In 10 ms wired network latency, SCONE maintains an 8.1% latency advantage over Choir; however, Choir exhibits a 33.8% to 88.9% latency reduction relative to other solutions. Even under 20 ms wired network
30 20
150 100 50
10 1
10 Wired Network Latency (ms)
20
1
(a) Average Frame Delay
10 Wired Network Latency (ms)
SCReAM SQP SCReAM+L4S COPA Pudica ABC Choir SCONE
250 200 150 100
Average Bitrate (Mbps)
40
SCReAM SQP SCReAM+L4S COPA Pudica ABC Choir SCONE
200
99.9th Frame Delay (ms)
50
95th Frame Delay (ms)
Average Frame Delay (ms)
SCReAM SQP SCReAM+L4S COPA Pudica ABC Choir SCONE
60
50
20
16
Choir ABC Pudica SCONE SCReAM+L4S SQP SCReAM COPA
14 12 10
1
(b) 95th Frame Delay
18
10 Wired Network Latency (ms)
1
20
(c) 99.9th Frame Delay
10 Wired Network Latency (ms)
20
(d) Average Bitrate
40 30 20 1
10 Wired Network Latency (ms)
(a) Average Frame Delay
20
100 80 60 40 1
10 Wired Network Latency (ms)
SCReAM SQP Pudica COPA SCReAM+L4S ABC Choir SCONE
200 175 150 125 100 75 50
20
20 Choir Pudica ABC SCReAM+L4S SQP SCReAM COPA SCONE
18 16 14
1
(b) 95th Frame Delay
Average Bitrate (Mbps)
50
SCReAM SQP SCReAM+L4S COPA Pudica ABC Choir SCONE
120
99.9th Frame Delay (ms)
SCReAM SQP SCReAM+L4S COPA Pudica ABC Choir SCONE
60
95th Frame Delay (ms)
Average Frame Delay (ms)
Figure 6: Bitrate and frame delay achieved by 8 control solution in trace-driven simulation.
10 Wired Network Latency (ms)
1
20
(c) 99.9th Frame Delay
10 Wired Network Latency (ms)
20
(d) Average Bitrate
Figure 7: Bitrate and frame delay achieved by 8 control solution in B210 RAN. 1.0
1.0
0.8
0.8
0.4 0.2 0.0 0
50
SCONE Choir Pudica ABC COPA SCReAM+L4S SQP SCReAM 100 150 200 250 Frame Delay (ms)
(a) Delay
0.6 CDF
0.6 CDF
latency, where SCONE outperforms Choir by 19.2% in tail latency, Choir sustains a 51.4% to 81.6% latency reduction compared to other solutions. In terms of average bitrate, Choir exhibits minimal tradeoffs against top-performing solutions while significantly outperforming lower-performing alternatives across varied network latency conditions. Under 1 ms wired network latency, Choir reduces the average bitrate by a marginal 0.7% compared to the best-performing method but exceeds lowerperforming solutions by 2.6% to 19.3%. At 10 ms wired network latency, the reduction relative to the top method narrows to 0.4%, while improvements over lower-performing solutions range from 2.3% to 79.5%. Under 20 ms wired network latency, Choir’s average bitrate decreases by 3.3% compared to the optimal baseline but achieves an 11.0% to 89.9% enhancement over suboptimal alternatives. Compared to other solutions, Choir leverages its predictive rate control design and demonstrates superior performance at higher wired network latency while maintaining high frame quality. Fig. 7 further proves Choir achieves the nearly lowest frame delay while maintaining the highest average bitrate, among the 8 solutions tested in the B210 RAN. Choir also ensures minimal variation in average bitrate. For 99.9th percentile tail latency, in 20 ms network latency scenarios, SCONE’s tail latency becomes comparable to Choir, while Choir maintains 7.10% to 68.64% latency reduction over existing solutions. In terms of average bitrate, at 10 ms wired network latency, Choir surpasses the SOTA base-
0.4 0.2 0.0 0
Choir ABC Pudica SCONE SQP SCReAM+L4S SCReAM COPA 10 20 30 40 Frame Bitrate (Mbps)
(b) Bitrate
Figure 8: The distribution of delay (a) and bitrate (b) of 8 control solution in 10ms wired network latency.
line by 0.23% and outperforms weaker solutions by 1.45% to 27.64%. Under 20 ms wired network latency, Choir achieves a 1.57% improvement over the optimal benchmark while delivering 4.52% to 37.13% higher bitrates than other baselines. When the wired network latency exceeds the update interval of the encoder, the returned available bandwidth will lag behind a bitrate adjustment, which is detrimental to the sender to react to instantaneous RAN fluctuations, potentially causing some queuing in the base station and increased latency. The results of Choir show that the frame tail delay increase was nearly identical to the basic RTT growth, indicating that the impact of a longer feedback path on Choir is limited. Overall, Choir’s holistic performance surpasses SOTA rate control solutions, striking an comprehensive optimal performance between latency, throughput, and fairness. As shown in Fig. 8a, markers are placed at the 95th percentile delay.
1
10 Wired Network Latency (ms)
(a) Average Frame Delay
20
SCReAM SQP SCReAM+L4S COPA Pudica ABC Choir SCONE
100 80 60 40 1
10 Wired Network Latency (ms)
(b) 95th Frame Delay
20
200 180 160 140 120 100 80 60 40
SCReAM SQP Pudica COPA SCReAM+L4S ABC Choir SCONE
1
10 Wired Network Latency (ms)
34 Average Bitrate (Mbps)
120
99.9th Frame Delay (ms)
SCReAM SQP SCReAM+L4S COPA Pudica ABC Choir SCONE
95th Frame Delay (ms)
Average Frame Delay (ms)
55 50 45 40 35 30 25 20
20
(c) 99.9th Frame Delay
32 Choir Pudica ABC SCReAM+L4S SQP SCReAM COPA SCONE
30 28 26 24 22
1
10 Wired Network Latency (ms)
20
(d) Average Bitrate
Figure 9: Bitrate and frame delay achieved by 8 control solution in openXG RAN.
Average Bitrate (Mbps)
19 Choir-1ms Choir-10ms Choir-20ms SCONE-1ms SCONE-10ms SCONE-20ms Pudica-1ms Pudica-10ms Pudica-20ms ABC-1ms ABC-10ms ABC-20ms
18 17 16 15 20
30
40 50 60 99th Percentile Delay (ms)
70
80
Figure 10: Comparison of bitrate and tail delay of 4 solutions. As shown in Fig. 8b, where markers are placed at the average bitrate, Choir maintains an equivalent average bitrate compared to higher-performing solutions, with only a 0.5% reduction compared to the best-performing method. Compared to lower-performing solutions, Choir increases the average bitrate by 27% to 80%. These results demonstrate that Choir achieves lower video frame delay while maintaining higher bandwidth utilization. As shown in Fig. 16, we selected the best-performing solutions from the previous analysis: ABC, Pudica, and SCONE. SCONE detects real-time queue buildup and forces the sender to drain it immediately, enabling extremely low tail delay. But Choir consistently appears in the upper-left, indicating that it effectively balances frame delay and bandwidth utilization. Compared to the baselines, Choir demonstrates faster and more stable adaptation to both bandwidth decreases and increases. When bandwidth suddenly decreases, Choir’s sender quickly responds to congestion, allowing it to rapidly drain the base station queue. This process is designed to be completed within a single frame interval in the optimal case. Once the queue is cleared, Choir restores its bitrate, ensuring efficient link utilization.
5.3 Performance of multi-flows concurrent transmission We tested 7-flow concurrency schemes for 8 solutions to fully utilize the OpenXG RAN capacity. In the openXG RAN, the bitrate of each flow increased significantly. Larger frame
Table 2: Performance of concurrent Choir flows at 1ms wired network delay Metrics P99.9 Delay (ms) P95 Delay (ms) Avg Delay (ms) Avg Bitrate (Mbps)
7 flow 37.06 27.03 18.23 7 × 34.85
14 flows 37.72 26.88 18.03 14 × 17.41
Table 3: Performance of concurrent Choir flows at 10ms wired network delay Metrics P99.9 Delay (ms) P95 Delay (ms) Avg Delay (ms) Avg Bitrate (Mbps)
7 flow 46.17 36.15 27.21 7 × 34.07
14 flows 50.40 36.04 27.05 14 × 17.04
sizes in high-bitrate video streams make it easier to cause severe congestion at the base station during multi-stream burst concurrency. Experimental results in the Fig. 9 demonstrate the performance of one flow in each 7-flow concurrency scenario. All Choir flows achieve fair resource utilization, resulting in consistent performance across flows. Other solutions exhibit uneven resource allocation, failing to ensure strict fairness. We select and show one flow with average performance. For 99.9th percentile tail latency, under 1ms wired network latency, Choir reduces tail latency by 3.77% to 56.48% compared to other algorithms, except for SCONE, which exhibits 2.15% lower tail latency than Choir. At 10ms wired network latency, Choir achieves 9.79% to 53.41% lower tail latency relative to alternative approaches, with SCONE marginally outperforming Choir by 2.45%. Under 20ms wired network latency, Choir demonstrates significant latency reduction, ranging from 20.04% to 71.67% compared to other baselines, while SCONE maintains a slight advantage of 2.41% lower tail latency over Choir. For average bitrate, under 1ms wired network latency, Choir achieves an average bitrate improvement of 2.51% to 28.88%
Table 4: Performance of concurrent Choir flows at 20ms wired network delay 7 flow 56.47 46.25 37.20 7 × 33.42
25 Bitrate (Mbps)
14 flows 74.258 46.23 37.10 14 × 16.70
30
40
Time (seconds)
50
60
70
Bandwidth (bps)
Figure 11: Fairness of Choir. compared to existing solutions. At 10ms wired network latency, Choir demonstrates a more pronounced enhancement, increasing the average bitrate by 2.86% to 35.04% over alternative approaches. For scenarios with 20ms wired network latency, Choir maintains robust performance, delivering a 4.73% to 31.76% improvement in average bitrate relative to all baselines. Further, we scaled Choir’s concurrent flows from 7 to 14 to observe its performance under full base station load. As shown in Table 2, Table 3 and Table 4, Choir maintains fair bandwidth allocation across 14 flows with no significant rise in tail delay. Fairness.The base station continuously collects, reclaims, and equally distributes bandwidth resources to all users with active queues. Therefore, whether it is fairness among multiple Choir flows, fairness between Choir flows and other flows, or background flows, the base station takes responsibility. Fig. 11 shows the fairness performance of Choir during 4-stream transmission.
5.4
4
6 Timeline (s)
Choir Deep Dive
Impact of varied wired network latency. Fig. 12 presents the bitrate variations of Choir under different wired network latency, alongside the bandwidth fluctuation trends from real 5G traces used in our simulation experiments. Choir could converge effectively to the available bandwidth at lower network latency, such as 1ms. However, as wired network latency increases, Choir’s bitrate fluctuations become more pronounced, reflecting the challenges introduced by increased feedback delay, which makes accurate predictions more difficult. Despite this, Choir strives to converge to the available bandwidth as closely as possible and keeps best performance among all compared
17.5 15.0 12.5 10.0 7.5 5.0 2.5 0.0
1-Frame
8
2-Frame
99th Percentile Delay (ms)
20
Avarage Bitrate (Mbps)
10
2
Default
10
Choir
3-Frame
25 20 15 10 5 0
SCONE
Choir
SCONE
Figure 13: Comparison of different ACK frequencies
solutions, demonstrating its adaptability to varying network conditions. Considering that selective acknowledgement mechanisms may reduce the frequency and quantity of ACK packets, thereby degrading the feedback timeliness of base station , we evaluate Choir and SCONE under lower ACK intervals (one ACK per 1/2/3 frames). As shown in the Fig. 13, Choir effectively adapts to different ACK frequencies, maintaining a relatively stable bitrate. Tail delay increases slightly in lower ACK frequency is also reasonable. Impact of smoothed bitrate control. We configure the smoothing factor of sender rate control algorithm to 1, 5, 10, and 20. As shown in Fig. 14, as the smoothing factor increases, robustness improves, leading to smaller variations in video bitrate. However, this also results in a higher 99th percentile tail delay, indicating a trade-off between bitrate stability and delay performance.
CDF
0
0
Figure 12: Frame bitrate variation.
1 0
10
0
Flow 1 Flow 2 Flow 3 Flow 4
2
15
5
1e6 3
20
1.0
1.0
0.8
0.8
0.6
0.6
0.4 0.2 0.0 0
CDF
Metrics P99.9 Delay (ms) P95 Delay (ms) Avg Delay (ms) Avg Bitrate (Mbps)
BandWidth Choir_20ms Choir_10ms Choir_1ms
30
Choir-1 Choir-5 Choir-10 Choir-20 50 100 150 200 Frame Delay (ms)
(a) Delay
Choir-1 Choir-5 Choir-10 Choir-20
0.4 0.2 0.0 0
5
10 15 20 Bitrate (Mbps)
(b) Bitrate
Figure 14: The impact of smoothing factor.
25
6
Discussion
Robust fairness under adversarial sender behavior. Base station inherently mitigates adversarial sender behaviors. Even if a sender bypasses Choir’s rate control algorithm, it cannot degrade other flows’ performance. The base station enforces balanced bandwidth allocation across flows. Senders exceeding allocated bandwidth by raising bitrates only incur higher tail delay, while reducing bitrates fails to meaningfully lower delay and may compromise throughput. Thus, we recommend senders strictly adhere to the guidance bandwidth to maximize capacity utilization and achieve optimal performance. Deployability. Both RTP streams and QUIC/TCP streams support IP options and do not require receiver-side participation for deployment. Many network-assisted solutions like ABC and L4S, necessitates involvement from the sender, network nodes, and receiver. Choir only requires recognition by the sender and base station, thereby enabling easier deployment. Overhead. The computational overhead of Choir and L4S at the base station is approximately the same, as both conduct estimation based on bandwidth and queue conditions. However, Choir reduces communication overhead by returning directly to the server without requiring additional processing through the UE.
7
Related Work
Numerous explorations have been conducted regarding endto-end low-latency transmission. Partial research focuses on sender-side optimization. For instance, Confucius [39] enhances congestion control effectiveness by proactively moderating bandwidth allocation at access points, though this strategy exhibits weak correlation with RTBC. The AFR [40] scheme further exploits the sender’s capability to actively adapt to link state variations. From the client-side perspective, JitBright [41] proposes improving real-time streaming experiences through jitter buffer optimization. For end-to-end latency minimization, diverse strategies have been explored. Approaches such as Copa, SQP, and Pudica effectively reduce latency through sophisticated endto-end congestion detection techniques. However, these methods remain constrained by reaction lag due to the inherent propagation delay between detection and response. To address this, solutions like Hairpin [42] and Tambur [43] introduce Forward Error Correction (FEC) to mitigate packet loss, thereby indirectly improving latency performance, particularly in mobile network environments. Hairpin [42] effectively integrates FEC with link-layer retransmission mechanisms to mitigate data packet loss in wireless environments. Additionally, several works attempt to integrate deep reinforcement learning for video bitrate adaptation, including Learning Congestion Control [44], ONRL [45], and LOKI
[46]. These methods inherit GCC’s limitations in fairness and robustness, and struggle to address cross-traffic fairness challenges.
8
Conclusion
Existing rate control solutions aiming to achieve the Performance Triangle of RTBC often have to make tradeoff decisions among the three metrics: high throughput, low delay and fairness. The native dynamic delay caused by underlying architecture of 5G RAN is the root cause. But the native resource fairness allocation strategy provides us the opportunity to achieve the Performance Triangle with the collaboration of 5G base station. We proposes Choir, a innovative collaborative solution mainly deployed on 5G base stations that deeply integrates 5G radio characteristics and video streaming traffic patterns to guide sender-side efficient rate control. Extensive simulation and testbed evaluations demonstrate Choir’s significant performance on high average bitrate, low tail delay and inter-flow fairness over different 5G network scenarios.
References [1] Maria Torres Vega, Christos Liaskos, Sergi Abadal, Evangelos Papapetrou, Akshay Jain, Belkacem Mouhouche, Gökhan Kalem, Salih Ergüt, Marian Mach, Tomas Sabol, et al. Immersive interconnected virtual and augmented reality: A 5g and iot perspective. Journal of Network and Systems Management, 28:796–826, 2020. [2] HUAWEI-iLab. Cloudvr solution white paper. [3] Jose Luis Rubio-Tamayo, Manuel Gertrudix Barrio, and Francisco García García. Immersive environments and virtual reality: Systematic review and advances in communication, interaction and simulation. Multimodal technologies and interaction, 1(4):21, 2017. [4] Teemu Kämäräinen, Matti Siekkinen, Antti Ylä-Jääski, Wenxiao Zhang, and Pan Hui. A measurement study on achieving imperceptible latency in mobile cloud gaming. In Proceedings of the 8th ACM on Multimedia Systems Conference, pages 88–99, 2017. [5] Gaetano Carlucci, Luca De Cicco, Stefan Holmer, and Saverio Mascolo. Congestion control for web real-time communication. IEEE/ACM Transactions on Networking, 25(5):2629–2642, 2017. [6] Varun Singh, Albert Abello Lozano, and Jorg Ott. Performance analysis of receive-side real-time congestion
control for webrtc. In 2013 20th International Packet Video Workshop, pages 1–8. IEEE, 2013. [7] 3GPP. Release 16. https://www.3gpp.org/ specifications-technologies/releases/ release-16, 2024. [8] Ingemar Johansson and Zaheduzzaman Sarker. SelfClocked Rate Adaptation for Multimedia. RFC 8298, December 2017. [9] Venkat Arun and Hari Balakrishnan. Copa: Practical {Delay-Based} congestion control for the internet. In 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18), pages 329–342, 2018.
[17] Sangtae Ha, Injong Rhee, and Lisong Xu. Cubic: a new tcp-friendly high-speed tcp variant. ACM SIGOPS operating systems review, 42(5):64–74, 2008. [18] Yaxiong Xie, Fan Yi, and Kyle Jamieson. Pbe-cc: Congestion control via endpoint-centric, physical-layer bandwidth measurements. In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication, pages 451–464, 2020. [19] Kadangode Ramakrishnan, Sally Floyd, and David Black. The addition of explicit congestion notification (ecn) to ip. Technical report, 2001.
[10] Devdeep Ray, Connor Smith, Teng Wei, David Chu, and Srinivasan Seshan. Sqp: Congestion control for low-latency interactive video streaming. arXiv preprint arXiv:2207.11857, 2022.
[20] Jangwoo Son, Yago Sanchez, Cornelius Hellge, and Thomas Schierl. Adaptable l4s congestion control for cloud-based real-time streaming over 5g. IEEE Open Journal of Signal Processing, 2024.
[11] Shibo Wang, Shusen Yang, Xiao Kong, Chenglei Wu, Longwei Jiang, Chenren Xu, Cong Zhao, Xuesong Yang, Jianjun Xiao, Xin Liu, et al. Pudica: Toward {NearZero} queuing delay in congestion control for cloud gaming. In 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), pages 113–129, 2024.
[21] Bob Briscoe, Koen De Schepper, Olivier Tilmans, Mirja Kühlewind, Joakim Misund, Olga Albisser, and A Sajjad Ahmed. Implementing the’prague requirements’ for low latency low loss scalable throughput (l4s). Netdev 0x13, 2019.
[12] Prateesh Goyal, Anup Agarwal, Ravi Netravali, Mohammad Alizadeh, and Hari Balakrishnan. {ABC}: A simple explicit congestion controller for wireless networks. In 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20), pages 353–372, 2020. [13] K De Schepper, M Bagnulo, and G White. Rfc 9330: Low latency, low loss, and scalable throughput (l4s) internet service: Architecture, 2023. [14] Zili Meng, Yaning Guo, Chen Sun, Bo Wang, Justine Sherry, Hongqiang Harry Liu, and Mingwei Xu. Achieving consistent low latency for wireless real-time communications with the shortest control loop. In Proceedings of the ACM SIGCOMM 2022 Conference, pages 193– 206, 2022. [15] Hang Shi, Xuesong Geng, Qiangzhou Gao, Qinghua Wu, and Jiaxing Zhang. SCONE Real Time Communication Requirement. Internet-Draft draft-shi-scone-rtcrequirement-02, Internet Engineering Task Force, April 2025. Work in Progress. [16] Neal Cardwell, Yuchung Cheng, C Stephen Gunn, Soheil Hassas Yeganeh, and Van Jacobson. Bbr: Congestion-based congestion control: Measuring bottleneck bandwidth and round-trip propagation time. ACM Queue, 14(5):20–53, 2016.
[22] Lloyd Brown, Albert Gran Alcoz, Frank Cangialosi, Akshay Narayan, Mohammad Alizadeh, Hari Balakrishnan, Eric Friedman, Ethan Katz-Bassett, Arvind Krishnamurthy, Michael Schapira, et al. Principles for internet congestion management. In Proceedings of the ACM SIGCOMM 2024 Conference, pages 166–180, 2024. [23] William Sentosa, Balakrishnan Chandrasekaran, P Brighten Godfrey, and Haitham Hassanieh. Cellreplay: Towards accurate record-and-replay for cellular networks. NSDI 2025. [24] Natale Patriciello, Sandra Lagen, Biljana Bojovic, and Lorenza Giupponi. An e2e simulator for 5g nr networks. Simulation Modelling Practice and Theory, 96:101933, 2019. [25] Mattia Lecci, Andrea Zanella, and Michele Zorzi. An ns-3 implementation of a bursty traffic framework for virtual reality sources. In Proceedings of the 2021 Workshop on ns-3, pages 73–80, 2021. [26] Katerina Koutlia, Biljana Bojovic, Zoraze Ali, and Sandra Lagén. Calibration of the 5g-lena system level simulator in 3gpp reference scenarios. Simul. Model. Pract. Theory, 119:102580, 2022. [27] Florian Kaltenberger, Aloizio P Silva, Abhimanyu Gosain, Luhan Wang, and Tien-Thinh Nguyen. Openairinterface: Democratizing innovation in the 5g era. Computer Networks, 176:107284, 2020.
[28] WITCOMM. xgproduct. xgstation, 2023.
https://witcomm.net/
[29] OpenAirInterface. Openairinterface 5g: Feature set documentation. https://gitlab.eurecom.fr/ oai/openairinterface5g/blob/develop/doc/ FEATURE_SET.md. Accessed: 2024-10-09. [30] 3rd Generation Partnership Project (3GPP). Technical specification group radio access network; nr; radio resource control (rrc) protocol specification. 3GPP TS 38.331, September 2023. Version 17.7.0. [31] 3rd Generation Partnership Project (3GPP). Technical specification group radio access network; nr; radio link control (rlc) protocol specification. 3GPP TS 38.322, September 2023. Version 17.7.0. [32] 3GPP. 3GPP TS 23.288: Architecture enhancements for 5g system (5gs) to support network data analytics services. Technical Specification (TS) 23.288, 3rd Generation Partnership Project (3GPP), December 2019. Version 15.4.0. [33] Alibaba. XQUIC Library released by Alibaba is a crossplatform implementation of QUIC and HTTP/3 protocol. 2022. [34] Mathis Engelbart, Joerg Ott, and Spencer Dawkins. RTP over QUIC (RoQ). Internet-Draft draft-ietf-avtcorertp-over-quic-11, Internet Engineering Task Force, July 2024. Work in Progress. [35] Zhenbin Li, Shuping Peng, Chongfeng Xie, and Shuai Zhang. Application-aware IPv6 Networking (APN6) Encapsulation. Internet-Draft draft-li-6man-apn-ipv6encap-00, Internet Engineering Task Force, March 2024. Work in Progress. [36] Gaetano Carlucci, Luca De Cicco, Stefan Holmer, and Saverio Mascolo. Analysis and design of the google congestion control for web real-time communication (webrtc). In Proceedings of the 7th International Conference on Multimedia Systems, pages 1–12, 2016. [37] Xiaoqing Zhu, Rong Pan, M Ramalho, and S Mena. Network-assisted dynamic adaptation (nada): a unified congestion control scheme for real-time media. RFC 8698, 2020. [38] Songyang Zhang, Weimin Lei, Wei Zhang, and Yunchong Guan. Congestion control for rtp media: A comparison on simulated environment. In International Conference on Simulation Tools and Techniques, pages 43–52. Springer, 2019. [39] Zili Meng, Nirav Atre, Mingwei Xu, Justine Sherry, and Maria Apostolaki. Confucius: Achieving consistent
low latency with practical queue management for realtime communications. arXiv preprint arXiv:2310.18030, 2023. [40] Zili Meng, Tingfeng Wang, Yixin Shen, Bo Wang, Mingwei Xu, Rui Han, Honghao Liu, Venkat Arun, Hongxin Hu, and Xue Wei. Enabling high quality {Real-Time} communications with adaptive {Frame-Rate}. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), pages 1429–1450, 2023. [41] Yuankang Zhao, Qinghua Wu, Gerui Lv, Furong Yang, Jiuhai Zhang, Feng Peng, Yanmei Liu, Zhenyu Li, Ying Chen, Hongyu Guo, et al. Jitbright: towards low-latency mobile cloud rendering through jitter buffer optimization. In Proceedings of the 34th edition of the Workshop on Network and Operating System Support for Digital Audio and Video, pages 36–42, 2024. [42] Zili Meng, Xiao Kong, Jing Chen, Bo Wang, Mingwei Xu, Rui Han, Honghao Liu, Venkat Arun, Hongxin Hu, and Xue Wei. Hairpin: Rethinking packet loss recovery in edge-based interactive video streaming. In 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), pages 907–926, 2024. [43] Michael Rudow, Francis Y Yan, Abhishek Kumar, Ganesh Ananthanarayanan, Martin Ellis, and KV Rashmi. Tambur: Efficient loss recovery for videoconferencing via streaming codes. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), pages 953–971, 2023. [44] Anfu Zhou, Huanhuan Zhang, Guangyuan Su, Leilei Wu, Ruoxuan Ma, Zhen Meng, Xinyu Zhang, Xiufeng Xie, Huadong Ma, and Xiaojiang Chen. Learning to coordinate video codec with transport protocol for mobile video telephony. In The 25th Annual International Conference on Mobile Computing and Networking, pages 1–16, 2019. [45] Huanhuan Zhang, Anfu Zhou, Jiamin Lu, Ruoxuan Ma, Yuhan Hu, Cong Li, Xinyu Zhang, Huadong Ma, and Xiaojiang Chen. Onrl: Improving mobile video telephony via online reinforcement learning. In Proceedings of the 26th Annual International Conference on Mobile Computing and Networking, pages 1–14, 2020. [46] Huanhuan Zhang, Anfu Zhou, Yuhan Hu, Chaoyue Li, Guangping Wang, Xinyu Zhang, Huadong Ma, Leilei Wu, Aiyun Chen, and Changhui Wu. Loki: improving long tail performance of learning-based real-time video adaptation by fusing rule-based models. In Proceedings of the 27th Annual International Conference on Mobile Computing and Networking, pages 775–788, 2021.
Openxg bandwidth trace and b210 bandwidth trace
BandWidth 300
Bitrate (Mbps)
250 200 150 100 50 0
0
2
4
6
8 Timeline (s)
10
12
14
Figure 15: Openxg bandwidth trace.
BandWidth 40
Bitrate (Mbps)
A
30 20 10 0
0
1
2
3 Timeline (s)
4
5
Figure 16: B210 bandwidth trace.