Pith. sign in

REVIEW 4 major objections 5 minor 15 references

Enabling Beyond-Visual-Line-of-Sight Drones Operation over Open RAN 5G Networks with Slicing

T0 review · 4 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read An open-source O-RAN 5G testbed with network slicing keeps drone command latency inside 3GPP BVLoS limits and cuts congestion-induced trajectory error from 2.4 m to 1 m.

desk verdict Useful open-source O-RAN drone testbed with honest reporting, but the slicing-vs-PF comparison is confounded by unequal resource shares. read the letter →

arxiv 2608.09481 v1 pith:IIRCX5MI submitted 2026-08-10 cs.NI

Pau Baguer , Esteban Municio , Gines Garcia-Aviles , Xavier Costa-Pérez This is my paper · ORCID
classification cs.NI
keywords DronesUAV5GO-RANnetworkslicingBVLoSQotrajectoryerror
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Beyond-visual-line-of-sight (BVLoS) drone flight requires command links that stay within strict latency limits while the same network carries video and other load; this paper claims that network slicing on an open, programmable 5G radio network can deliver that protection. If true, the safety-critical control link of a drone could be protected by software on commodity open radio infrastructure rather than by dedicated hardware or spectrum. The authors built a full open-source O-RAN testbed with a simulated drone, a software-defined-radio base station, and a near-real-time controller, and used a controller application to reserve a slice for command-and-control and first-person-view video. Under congestion, ordinary proportional-fair scheduling produced a maximum trajectory error of 2.4 m; slicing held it to 1 m and kept steering-command latency near 10 ms and FPV video near 25 ms, below the 3GPP ceilings of 40 ms and 140 ms. The paper also documents FPV bursts that exceed the limit, so the claim is that open-source O-RAN slicing makes BVLoS operation feasible in controlled conditions, not that it already delivers carrier-grade dependability.

What carries the argument

The load-bearing mechanism is slot-based network slicing implemented inside the 5G base station and configured over the O-RAN E2 interface. A slice allocation gives the drone's command-and-control and first-person-view flows two-thirds of the radio resources while the competing bulk traffic is confined to the remaining one-third, so congestion in the shared cell cannot starve the priority flows. The O-RAN E2 service model is what turns this from a static configuration into a closed loop: an xApp (a control application on the near-real-time controller) can change slice weights through the interface, which is the same path future AI-based optimizers would use. The experiments compare this mechanism against the default proportional-fair scheduler on the same open-source stack.

What would settle it

Run the same slicing configuration on a real drone in a multi-cell deployment with handover and neighboring-cell interference while a bulk flow congests the serving cell. If the command-and-control latency exceeds the 40 ms 3GPP ceiling, or the trajectory error grows beyond the 1 m seen in simulation, the paper's central claim that open-source O-RAN slicing protects BVLoS control under congestion is falsified for field conditions.

Watch

Extended reading notes

Core claim

The central discovery is that a slot-based network slicing mechanism, implemented inside an open-source 5G base station and steered by a near-real-time controller over the O-RAN E2 interface, can isolate the critical uplink and downlink flows of a BVLoS drone mission from best-effort traffic on the same cell. With proportional-fair scheduling, the arrival of a bulk flow roughly halves the high-priority throughput and causes latency to rise linearly, which translates into a maximum trajectory deviation of 2.4 m and telemetry that lags the true position; with slicing, the priority flow keeps a constant two-thirds share of the resources, latency stays below 8 ms downlink and 20 ms uplink in link tests, steering commands average about 10 ms, FPV video averages about 25 ms, and the maximum trajectory error drops to 1 m. This is presented as evidence that the closed loop over the E2 interface works at the timescale needed for drone control, while the remaining latency spikes in FPV video show that slice dimensioning must be paired with bandwidth-stable video or adaptive resource control to meet the 3GPP threshold in every burst.

Load-bearing premise

The lab testbed—a single base station on software-defined radios, a simulated drone, and controlled RF conditions with no handovers—stands in for real beyond-visual-line-of-sight field conditions closely enough that the measured latencies and trajectory errors transfer.

Editorial extensions

If this is right

  • A single shared 5G cell can host a BVLoS drone mission alongside other traffic without dedicated spectrum, provided the control and FPV flows are placed in their own slice.
  • The same E2 control loop that assigns slice weights can also carry future optimizers, such as AI-based slice resizing, so the measured results are a baseline for what the architecture can do.
  • Because trajectory error stayed at or below 1 m with slicing under congestion, the practical gap to dependable BVLoS lies in the documented video bursts and unmeasured field effects such as handover, not in the basic isolation mechanism.
  • Under slicing, latency cost is shifted from the protected drone flows to the best-effort surveillance flow, so the network operator must decide whether secondary real-time video also needs its own slice or more capacity.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • An immediate testable extension is to replace slot-based slicing with resource-block-based slicing; the paper itself notes that slot granularity limits transmission opportunities, so RB-level control should shrink the remaining FPV latency bursts at the cost of more computation.
  • The measured 1 m trajectory-error ceiling could be translated into a C2 latency budget for real flights: given the drone's speed and the autopilot's response, one can compute how much extra command latency the control loop can tolerate before error exceeds a meter, and use that number to dimension the slice.
  • Comparing commanded versus executed trajectories with Fréchet distance or Dynamic Time Warping, metrics the paper suggests, would let different BVLoS testbeds be scored on a common scale; a shared trajectory-error benchmark is a cheap community extension the paper leaves implicit.
  • The slicing controller has only been tested on a single cell with no handover; a multi-cell trial would test whether the E2 loop can re-provision the slice fast enough during handover, which is the most likely field condition to break the 40 ms command budget.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. This paper describes a laboratory deployment of an open-source O-RAN 5G system, built with Open Air Interface (OAI), FlexRIC, and PX4 Software-in-the-Loop (SITL), to evaluate whether network slicing can support Beyond-Visual-Line-of-Sight (BVLoS) drone operation. The authors characterize link throughput and latency under two configurations: the default OAI Proportional Fair scheduler and a slot-based network slicing scheme controlled through the O-RAN E2 interface. They then measure trajectory deviation, telemetry accuracy, and FPV/surveillance video latency, comparing them against 3GPP TS 22.125 limits of 40 ms for C2 latency and 140 ms for FPV video. The paper reports that slicing reduces maximum trajectory error from 2.4 m to 1 m and keeps latency mostly below the 3GPP thresholds, while acknowledging occasional latency peaks. The authors conclude that open-source O-RAN 5G with slicing is a promising enabler for BVLoS drone operations.

Significance. If the central comparison were clean, the paper would provide a valuable experimental demonstration that O-RAN E2-interface slicing on an open-source 5G stack can protect drone control traffic from competing congestion. The engineering integration of FlexRIC, OAI, and PX4 and the use of an external 3GPP benchmark are concrete strengths, and the authors are candid about several limitations. However, the key causal claim that slicing, rather than simple resource-share allocation, improves latency and trajectory accuracy is not yet established because the slicing configuration is not compared with a control condition that holds the priority flow's resource share fixed. In addition, the paper's own reported latency peaks contradict the abstract's sweeping compliance claim, and all quantitative results come from single runs without error bars. The contribution is therefore promising but currently overstated.

major comments (4)
  1. [Section IV-A, Fig. 2] The comparison between PF scheduling and slicing is confounded by resource share. The text states that the slicing configuration allocates two-thirds of resources to the high-priority flow and one-third to the bulk flow, whereas the PF scheduler, after the bulk flow starts, shares capacity equally at 50/50. The latency advantage in Fig. 2(b) and the trajectory-error improvement in Section IV-B (2.4 m vs. 1 m) are therefore equally consistent with a simple effect of allocating a larger resource share to the prioritized flow, rather than with any isolation property of slicing. A control condition holding the high-priority resource share fixed (e.g., slicing with a 50/50 split, or weighted PF giving the priority flow two-thirds of resources) is needed to attribute the improvement to slicing. This is the central comparison of the paper, so the claim that slicing protects BVLoS control traffic from congestion is not yet established.
  2. [Section IV-C, Fig. 4] The paper's own data contradict the abstract's claim that latency is kept 'well below the 3GPP limits.' The text in Section IV-C explicitly says that 'bursty FPV behaviors may deplete the capacity of the slice and sporadically trigger the latency over the threshold,' and Fig. 4 shows FPV video latency peaks exceeding the 140 ms line. Since 3GPP compliance is a central goal, the paper should quantify the frequency and magnitude of threshold violations and report them honestly in the abstract and conclusions, rather than stating blanket compliance.
  3. [Section IV-C, last paragraph] The explanation for steering-command latency is internally inconsistent with Section IV-A. In Section IV-A the authors say that slot-based slicing creates fewer transmission opportunities for the priority slice, so its latency is slightly higher than with PF; in the last paragraph of Section IV-C they write that with slicing 'there are more transmission opportunities which makes its latency even lower.' One of these statements must be wrong. This contradiction directly affects how the steering-command latency results should be interpreted.
  4. [Sections IV-A through IV-C] All numerical results are reported for single experimental runs: throughput traces, latency traces, FPV video latency, and trajectory error are each shown as one curve per configuration, with no error bars, confidence intervals, or repeated trials. Given that the central quantitative claims depend on comparing two configurations (PF vs. slicing), the absence of variability information makes it impossible to assess whether the observed differences are statistically meaningful. The paper should report multiple runs and the spread of results, ideally with paired comparisons.
minor comments (5)
  1. [Abstract] The abstract calls the deployment a 'state-of-the-art 5G O-RAN open-source BVLoS operational system,' but the evaluation uses PX4 SITL, a simulated drone, not a physical aircraft. The wording should reflect that this is a laboratory, simulation-based validation.
  2. [Figure 2 caption] The caption 'Slicing-enabled 5G link characterization' is misleading because the figure also includes the PF scheduling results; it should say that the figure compares slicing with default PF scheduling.
  3. [Figure 4 caption] The caption states 'Communication latency for FPV and Surveillance video in DL,' but the scenario in Section III-B defines FPV video as an uplink stream. The caption should say UL, or the flow directions should be clarified.
  4. [Section V] The text mentions 'Dynamic Time Wrapping' as a proposed metric; the standard term is 'Dynamic Time Warping.'
  5. [Section IV-A] The sentence beginning 'To conduct a thorough assessment of the system described in Section III-B' appears to reference the wrong subsection; the deployment is described in Section III-A and the testing methodology in Section III-B.

Circularity Check

0 steps flagged · score 1.0 of 10

Slicing benefit is empirically measured against an in-testbed PF baseline and an external 3GPP benchmark; only non-load-bearing author self-citation.

full rationale

This is an experimental deployment/evaluation paper, not a derivation chain. The central claim—that O-RAN E2-based network slicing keeps C2 and FPV latencies below the 3GPP TS 22.125 bounds and reduces trajectory error relative to the OAI Proportional Fair scheduler under congestion—is supported by direct measurements against an external benchmark (3GPP) and an in-testbed baseline (OAI PF). No parameter is fitted to a subset of the data and then renamed as a prediction; the resource split (2/3 priority, 1/3 bulk under slicing vs 50/50 under PF) is a test configuration, not a fit, and the reported latencies/errors are observed quantities that could in principle have gone the other way (indeed, the authors report slightly higher priority-slice latency before congestion due to fewer TX opportunities). The only author-overlap citation is DeepCog [15], used as an example that over-provisioning (5-20%) can keep a slice below a latency threshold with high probability; this supports a forward-looking remark, not the paper's main result, so it is not load-bearing. The resource-share confound noted by readers is a correctness/internal-validity concern about whether slicing's benefit stems from isolation or from a larger resource share; that is not a circularity of the 'prediction equals input' type. No circular step can be exhibited with a specific equation or fitted-parameter reduction.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new theoretical entities. The slot-based slicing procedure is an implementation of existing slicing concepts, not an invented entity. The main hand-chosen input is the slice resource split (2/3 vs 1/3). The other assumptions are standard domain assumptions about the testbed being representative.

free parameters (1)
  • Slice resource split = 2/3 high-priority, 1/3 default
    Chosen by hand in Section IV-A; all subsequent trajectory and video results use this split. No sensitivity analysis is provided, so results could depend on this allocation.
assumptions (4)
  • domain assumption 3GPP TS 22.125 defines the applicable BVLoS latency requirements (40 ms C2, 140 ms FPV)
    The paper evaluates compliance against these thresholds, treating them as authoritative without discussing whether other UAS requirements (e.g., reliability, positioning) are also binding.
  • domain assumption PX4 Software-in-the-Loop flight simulation accurately reproduces drone dynamics and network-induced trajectory deviations
    Trajectory errors are attributed to network latency, which requires the simulator to respond realistically to delayed or congested control commands.
  • domain assumption OAI's Proportional Fair scheduler is a fair baseline representing a non-sliced 5G RAN
    The comparison assumes PF is the relevant default; other schedulers could give different baselines.
  • domain assumption USRP SDRs and the OAI PHY layer provide a representative 5G NR wireless link with negligible implementation-specific artifacts
    The measured latencies and throughputs are taken as indicative of a real 5G link, but the lab RF environment is controlled and small-scale.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Enabling Beyond-Visual-Line-of-Sight Drones Operation over Open RAN 5G Networks with Slicing." pith.science (2026). https://pith.science/paper/IIRCX5MI

@misc{pith2026260809481,
  author       = {Pith},
  title        = {Pith review of: Enabling Beyond-Visual-Line-of-Sight Drones Operation over Open RAN 5G Networks with Slicing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IIRCX5MI}},
  note         = {Machine review of arXiv:2608.09481}
}
read the original abstract

Among the foretold claims of the transition from 5G to 6G, Beyond-Visual-Line-of-Sight (BVLoS) drone operation has emerged as a prominent Internet-of-Robots enabler. However, safety concerns have been raised since BVLoS imposes strict requirements on performance and dependability on the technology, and requires robust regulatory frameworks. While current 5G technologies promise to meet the performance requirements in terms of throughput and latency, there is a lack of studies regarding how to achieve full reliability in practice. To address this challenge, the research community is actively working on open-source projects that allow for experimental validation in the field. Fortunately, new Open RAN (O-RAN) standards are paving the way for such approaches in an integrated, native manner. In this work, we deploy a state-of-the-art 5G O-RAN open-source BVLoS operational system, report current limitations, and address them via advanced capabilities natively available in O-RAN: Slicing. Our proposed deployment minimizes trajectory errors due to 5G link congestion and keeps latency well below the 3GPP limits defined for BVLoS operation. Finally, we discuss on the challenges ahead and the opportunities that 5G O-RAN-enabled networks may bring to BVLoS drone operation.

Figures

Figures reproduced from arXiv: 2608.09481 by the authors.

Figure 1
Figure 1. System architecture depicting the components that form the deployment for testing an O-RAN enabled 5G network for [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Slicing-enabled 5G link characterization [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Effects of traffic performance on drone trajectory [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Communication latency for FPV and Surveillance video in DL. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

15 extracted references · 15 canonical work pages

  1. [1]

    What will the future of UA V cellular communications be? A flight from 5G to 6G,

    G. Geraciet al., “What will the future of UA V cellular communications be? A flight from 5G to 6G,”IEEE communications surveys & tutorials, vol. 24, no. 3, 2022

    work page 2022

  2. [2]

    Drone Security and the Mysterious Case of DJI’s DroneID,

    N. Schilleret al., “Drone Security and the Mysterious Case of DJI’s DroneID,” inNetwork and Distributed System Security Symposium (NDSS), 2023

    work page 2023

  3. [3]

    First experiments with a 5G-Connected drone,

    R. Muzaffaret al., “First experiments with a 5G-Connected drone,” inProceedings of the 6th ACM Workshop on Micro Aerial V ehicle Networks, Systems, and Applications, 2020, pp. 1–5

    work page 2020

  4. [4]

    O-RAN: Disrupting the virtualized RAN ecosystem,

    A. Garcia-Saavedraet al., “O-RAN: Disrupting the virtualized RAN ecosystem,”IEEE Communications Standards Magazine, 2021

    work page 2021

  5. [5]

    5G; Unmanned Aerial System (UAS) support in 3GPP (TS 22.125 version 17.6.0 Release 17),

    ETSI 3GPP 5G, “5G; Unmanned Aerial System (UAS) support in 3GPP (TS 22.125 version 17.6.0 Release 17),” Tech. Rep., 2022

    work page 2022

  6. [6]

    An experimental analysis on drone-mounted access points for improved latency-reliability,

    I. Donevski, C. Raffelsberger, M. Sende, A. Fakhreddine, and J. J. Nielsen, “An experimental analysis on drone-mounted access points for improved latency-reliability,” inProceedings of the 7th Workshop on Micro Aerial V ehicle Networks, Systems, and Applications, 2021, pp. 31–36

    work page 2021

  7. [7]

    Analyzing real-time video delivery over cellular networks for remote piloting aerial vehicles,

    A. Baltaciet al., “Analyzing real-time video delivery over cellular networks for remote piloting aerial vehicles,” inProceedings of the 22nd ACM Internet Measurement Conference, 2022, pp. 98–112. 7

    work page 2022

  8. [8]

    Flying drones beyond visual line of sight using 4G LTE: Issues and concerns,

    W. D. Ivancicet al., “Flying drones beyond visual line of sight using 4G LTE: Issues and concerns,” in2019 Integrated Communications, Navigation and Surveillance Conference (ICNS). IEEE, 2019, pp. 1– 13

    work page 2019

Show all 15 references
  1. [9]

    Edge computing in 5G for drone navigation: What to offload?

    S. Hayatet al., “Edge computing in 5G for drone navigation: What to offload?”IEEE Robotics and Automation Letters, vol. 6, 2021

    2021

  2. [10]

    End-to-end performance measurements of drone communications in 5G cellular networks,

    A. Festaget al., “End-to-end performance measurements of drone communications in 5G cellular networks,” in2021 IEEE 94th V ehicular Technology Conference (VTC2021-Fall). IEEE, 2021, pp. 1–6

    2021

  3. [11]

    Xhaul latency dimensioning of 5G drone con- trol,

    L. M. Larsenet al., “Xhaul latency dimensioning of 5G drone con- trol,” in2022 International Conference on Unmanned Aircraft Systems (ICUAS). IEEE, 2022, pp. 762–771

    2022

  4. [12]

    Streaming from the air: Enabling drone-sourced video streaming applications on 5G Open-RAN architectures,

    L. Bertizzoloet al., “Streaming from the air: Enabling drone-sourced video streaming applications on 5G Open-RAN architectures,”IEEE Transactions on Mobile Computing, 2021

    2021

  5. [13]

    When RAN intelligent controller in O-RAN meets multi-UA V enable wireless network,

    C. Phamet al., “When RAN intelligent controller in O-RAN meets multi-UA V enable wireless network,”IEEE Transactions on Cloud Computing, 2022

    2022

  6. [14]

    Open RAN Testbeds with Controlled Air Mobility,

    M. Mushiet al., “Open RAN Testbeds with Controlled Air Mobility,” arXiv preprint arXiv:2301.11365, 2023

    2023 arXiv

  7. [15]

    DeepCog: Optimizing resource provisioning in network slicing with AI-based capacity forecasting,

    D. Bega, M. Gramaglia, M. Fiore, A. Banchs, and X. Costa-Perez, “DeepCog: Optimizing resource provisioning in network slicing with AI-based capacity forecasting,”IEEE Journal on Selected Areas in Communications, vol. 38, no. 2, pp. 361–376, 2019. Pau Baguercompleted a double e...

    2019

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.