Toward Lightweight Aerial 5G gNBs: Reproducible OAI Testbed on Commodity ARM Platforms

Toward Lightweight Aerial 5G gNBs: Reproducible OAI Testbed on Commodity ARM Platforms Marc Duboc and Ammar El Falou

arXiv:2610.05007v1 [cs.CR] 4 Oct 2026

King Abdullah University of Science and Technology (KAUST) Thuwal, Saudi Arabia Email: {marc.duboc, ammar.falou}@kaust.edu.sa

makes PWS a natural service requirement for the split aerial architecture. This architecture only helps if the airborne DU is small and practical without sacrificing too much radio performance. We deliberately evaluate two off-the-shelf ARM platforms— Raspberry Pi 5 and Jetson Orin Nano—rather than custom flight computers. They are widely available, well documented, and easy for academic laboratories to source, while spanning a useful range from a low-complexity single-board computer to a higher-performance embedded platform. The objective is not to argue that ARM is intrinsically superior to x86; it is to quantify the performance price paid when choosing commodity embedded compute to make a reproducible airborne DU practical. This leads to three experimental questions. RQ1: how much throughput is lost when the DU moves from x86 to commodity ARM under the same real-radio access configuration? RQ2: how much additional penalty appears when F1 moves from wired Ethernet to untethered Wi-Fi/GRE or 5G/WireGuard? RQ3: Which lower-layer failures can destroy useful throughput even while F1, registration, and IP connectivity remain healthy? We answer them with a fixed B210/UE/n78 access profile, repeated measurements, and a layered acceptance contract. The paper answers these questions with three measured results and contributes one additional split-RAN capability: • a reproducible UAV-oriented remote-cell design that keeps 5GC/CU on the ground, uses laboratory-accessible ARM I. I NTRODUCTION as DUs, and measures the integrated Jetson/B210/5Gbackhaul payload at 657.4 g and approximately consumes UAV-mounted cellular base stations are attractive for tem28 W; porary coverage, emergency response, and rapidly deployable • a 400-observation host–bearer benchmark that quantifies networks, but they face a hard systems constraint: payload the throughput cost of embedded compute and heterogemass and electrical load directly consume the aircraft’s limited neous F1 under a fixed 106-PRB real-radio configuration; energy budget. Carrying a complete base station, therefore • an instrumented failure study: a controlled BLER/MCS spends valuable airborne resources on functions that do not intervention recovers a 4.25× throughput collapse, while need to be close to the radio. The 3GPP F1 split provides a synchronized mono/split telemetry narrows the residual natural boundary: RRC/PDCP/SDAP remain in the CU on the split penalty to scheduling/timing behavior; ground, while the latency-sensitive RLC/MAC/PHY stay in • A documented OAI PWS-over-F1 implementation: a patch the DU next to the radio; F1-C uses F1AP/SCTP, and F1-U that carries the F1AP Write-Replace Warning procedure uses GTP-U/UDP [1], [2]. The intended airborne payload can from the ground CU to the remote DU, enabling area-wide consequently be reduced to a backhaul endpoint, DU, SDR, emergency alerts [3]. and antennas rather than an entire gNB stack. In a disaster area, a particularly valuable first service from such a temporary cell Concurrent two-DU operation is retained as a first-step is an emergency broadcast: PWS can deliver the same warning replication check. The novelty is therefore a measured and or instruction to compatible handsets in the covered area. This reproducible airborne payload/performance trade-off plus an

Abstract—For a battery-powered UAV base station, every gram and watt devoted to RAN-compute competes with flight-duration margin. We therefore keep the 5G Core (5GC) and central unit (CU) on the ground and design the airborne unit around only the backhaul endpoint, distributed unit (DU), and radio. The key question is then a practical one: can widely available commodity ARM computers sustain a real radio OpenAirInterface (OAI) 5G DU with useful performance over heterogeneous F1? We answer it with Raspberry Pi 5 and Jetson Orin Nano as DUs, a USRP B210, a commercial handset, and Ethernet, WiFi/GRE, and 5G/WireGuard backhaul. Jetson preserves 88.4% of x86 split-DU Ethernet DL throughput and 87.5–89.0% across all three bearers; 5G/WireGuard preserves 76.4–77.1% of each host’s wired DL rate. The validated Jetson/B210/RM500Q-GL electronics weigh 657.4 g and draw about 28 W under sustained traffic (757.4 g with integration allowance). A controlled linkadaptation intervention raises split DL from 23.4 to 99.4 Mb/s as the dominant Modulation and Coding Scheme (MCS) moves from 3 to 26. Finally, synchronized radio, F1-U, CPU, and UHD evidence narrows the remaining monolithic–split gap to split-path scheduling/timing behavior. Beyond performance, this capability serves the emergency-response use case that motivates the aerial cell: once deployed above an affected area, it can broadcast a PWS warning message. We release the OAI patch that carries the singlesegment Write-Replace Warning over F1 from CU to DU, where SIB8 is scheduled to the handset. The public artifact makes the payload, performance, and emergency-broadcast baseline reproducible with laboratory-accessible hardware. Index Terms—5G NR, OpenAirInterface, CU/DU split, F1, AArch64, ARM, testbed, software-defined radio, wireless backhaul, UAV, aerial RAN, public warning system

enabling public-service function for the split architecture, not the aerial-DU or wireless-F1 concept by itself. II. R ELATED W ORK AND P OSITIONING

can actually reproduce: how much radio performance is retained when the x86 DU is replaced by hardware that is realistic to carry and easy to source. The three F1 modes are implemented as distinct, packetverifiable paths rather than aliases over the same management network. The Ethernet profile uses a 9000-byte MTU on the CU/DU path and corresponding core bridge/veth path. The Wi-Fi profile carries the F1 addresses inside GRE over the wireless underlay. For 5G/WireGuard, one B210 serves the UE and a second, independent donor B210 serves the RM500Q-GL; F1 uses the WireGuard inner interface, while packet capture also verifies the modem-facing outer path. Every run checks that F1-C and F1-U do not leak to an unselected Ethernet, Wi-Fi, or management route [14]. This matters experimentally because a healthy SCTP association on the wrong interface would otherwise invalidate any backhaul comparison. The source tree is frozen at commit 102965a6 and built natively on ARM through OAI’s SIMDe-backed AArch64 path [10]. Jetson uses a matching L4T R36.4.4 / JetPack 6.2 SCTP-enabled kernel and rollback entry [15]. Stable B210 operation requires SuperSpeed USB, locked clocks, disabled USB autosuspend, bounded DU CPU placement, and xHCI interrupt isolation; USB 2 produces continuous UHD overflows. These details are retained because they determine whether the “lightweight” platform is a usable real-radio DU, while the full kernel procedure remains in the artifact.

Aerial cellular prototypes established the motivation for moving RAN functions onto aircraft. Flying Rebots, SkyRAN, and SkyCell demonstrated that open SDR cellular stacks can operate aloft on commodity x86-class compute [4], [5], [6]. Their key cost is that substantial base-station compute travels with every aircraft. An F1 split changes that scaling rule by sharing CU/5GC functions on the ground and repeating only the remote DU/radio payload. The closest predecessor is Mundlamuri et al., who demonstrated an OAI 5G aerial DU with a B200mini, Quectel 5G modem, wireless F1, and commercial terminals [7]. Our goal is not to show the aerial-DU concept, but to answer: what happens when the airborne DU is deliberately built from widely reproducible ARM computers, and how much performance is traded for that payload choice across several F1 paths? Recent non-aerial OAI systems provide complementary evidence. Authors in [8] implement an OAI CU/DU MUMIMO testbed, while [9] study intensive vRAN deployment across server-class compute architectures. OAI itself provides AArch64 portability through SIMDe [10], and a 2024 6GSPACE report documents Raspberry Pi execution with the RF simulator [11]. These works show that compute matters, but do not provide the same real-radio, commercial-UE host– backhaul comparison on commodity ARM. Prior PWS work B. Experimental Control and Measurement studies warning-system security [12]. We recently added openA run is accepted only if five independent gates pass: (i) source SIB8 transmission to a monolithic OAI gNB and kept core health; (ii) F1-C/SCTP and F1-U/GTP-U establishment; the implementation modular, specifically to ease future CU/DU (iii) packet capture proving that F1 uses the selected bearer support [13]. We close that disaggregation gap: our published rather than a management interface; (iv) UE registration, PDU patch implements the F1AP Write-Replace Warning path from session, external reachability, and PWS reception; and (v) CU to DU and validates the resulting SIB8 on a commercial clean teardown and Ethernet rollback. The isolated test PLMN handset [3]. To the best of our knowledge, no earlier public operates inside a Faraday cage with test-only warning text. OAI implementation demonstrates PWS delivery through an Host/radio identity, routes, USB speed, OAI revision, and patch actual F1 CU/DU split. Table I summarizes this section. state are recorded before each run [14]. Each host–bearer configuration uses 20 repetitions with the III. T ESTBED AND M ETHOD same UE, B210,n78/106-PRB profile, OAI revision, and gate A. UAV-Oriented Architecture and Commodity ARM Choice sequence. iperf3 TCP uses one stream for 30 s after a 5 s Fig. 1 makes the deployment boundary explicit. The x86 warm-up; DL and UL are measured separately, scenario order is ground host keeps the OAI 5GC/CU; only the backhaul randomized, and runs are separated by 10 s. The server is on the endpoint, ARM DU, B210, and antennas form the intended 5GC/CU side, so throughput traverses the complete UE–gNB– airborne unit. The DU runs RLC/MAC/PHY and drives the 5GC user plane. Reported repeated values are arithmetic means access B210 over USB 3. The access cell is fixed at band n78, over the 20 valid repetitions; failed service gates invalidate a 3.6192 GHz, 30-kHz SCS, and 106 PRBs, with a commercial run rather than create a zero-rate sample. Absolute RTT is not treated as a bearer metric because it Nothing Phone handset as the end-to-end UE. Ethernet provides the deterministic/tethered reference, while Wi-Fi/GRE and depends on responder placement and ground-network routing. 5G/WireGuard represent untethered F1 options. In the 5G Delay is instead reported as the paired location-induced change case, an RM500Q-GL modem camps on an independent donor ∆RTT(ℓ) = RTT(ℓ) − RTT(ℓ0 ), where ℓ0 is the on-premises CU-side responder and ℓ is the same service at a more distant gNB, so the access gNB never backhauls itself [14]. Raspberry Pi 5 and Jetson Orin Nano are chosen intentionally location; bearer, load, packet size, and test host are held fixed. as reproducible lab platforms rather than bespoke avionics. Pi 5 Table III separates transport context from handset-visible provides a widely available low-complexity ARM baseline; end-to-end throughput. The untethered paths impose clear Jetson represents the higher-performance embedded choice. The throughput penalties, but delay is not inferred from their raw experiment therefore measures a design trade-off a laboratory RTT because that number depends on endpoint placement and

TABLE I P OSITIONING AGAINST R EPRESENTATIVE A ERIAL AND OAI S PLIT-RAN S YSTEMS . VALUES ACROSS PAPERS ARE NOT DIRECT PERFORMANCE RANKINGS BECAUSE RADIOS , BANDWIDTHS , UE S , AND TRAFFIC DIFFER . System

RAN / Compute

Experimental focus

Gap Relative to This Work

Flying Rebots [4] Mundlamuri et al. [7]

OAI LTE eNB; x86; USRP OAI 5G DU; B200mini; Quectel wireless F1

Bui and Tran [8]

OAI 5GC/CU/DU; multi-UE NR

Beurdouche and Knopp [9] Abou Hasna et al. [13]

OAI vRAN; server-class GPP/accelerator platforms Modified monolithic OAI gNB; B210

This work

Ground 5GC/CU; commodity ARM remote DU; B210; three F1 paths

Aerial cellular relay Aerial DU; ∼30 Mb/s to commercial terminals MU-MIMO implementation and throughput Intensive multi-instance vRAN compute scaling Open-source SIB8/PWS security testbed 400 repeated DL/UL observations; PWS over F1; payload power/mass; failure diagnosis

Complete eNB aloft; no 5G F1 split or embedded ARM DU. Closest remote-DU predecessor; no repeated ARM host–bearer matrix or failure diagnosis. Functional CU/DU testbed; not embedded ARM or heterogeneous F1 characterization. Compute-focused central deployment; not remote ARM DUs with B210/UE and variable F1. Public SIB8 broadcast, but CU/DU disaggregation left as future support. Reproducible UAV-oriented study plus published CU-to-DU PWS Write-Replace Warning patch.

Replicate airborne block: DU2 → DUN Intended airborne payload – repeated per cell

Ground – shared once

OAI 5GC shared core

OAI CU RRC / PDCP SDAP

F1-C / F1-U

5GC/CU remain on the ground;

Backhaul Eth / Wi-Fi RM500Q 5G

ARM DU RLC / MAC PHY

USB 3

USRP B210 n78, 106 PRBs

NR-Uu Commercial UE data + PWS

Only this block is intended to fly.

Fig. 1. UAV-oriented split architecture. Shared 5GC/CU compute remains on the ground, while the repeated airborne unit contains only the F1 backhaul endpoint, commodity ARM DU, and access radio. The solid path is the measured single-DU configuration; concurrent DU2 serves as a supporting check, and larger fan-out is left for future work. TABLE II E XPERIMENTAL C ONFIGURATION H ELD F IXED U NLESS VARIED Item

Configuration

Deployment split

Ground: x86 5GC/CU; intended airborne unit: backhaul + DU + B210 commit 102965a6 USRP B210, USB 3; n78, 3.6192 GHz, 30-kHz SCS, 106 PRBs x86 reference; Raspberry Pi 5 (16 GB); Jetson Orin Nano commercial Nothing Phone handset Ethernet (MTU 9000); Wi-Fi/GRE; RM500Q-GL 5G/WireGuard L4T R36.4.4 / JetPack 6.2; SCTP-enabled kernel; locked clocks iperf3 TCP, one stream, 30 s + 5 s warm-up, separate DL/UL Faraday cage; same B210/UE/access profile for paired tests

OAI Access radio DU hosts UE F1 paths Jetson SW Traffic RF control

TABLE III M EASURED X 86 S PLIT F1-B EARER T HROUGHPUT BASELINE (n = 20) F1 bearer Ethernet Wi-Fi/GRE 5G/WireGuard

DL throughput (Mb/s)

UL throughput (Mb/s)

99.4 51.8 76.2

22.6 12.1 18.9

IV. R ESULTS A. The Cost of Moving the DU from x86 to Commodity ARM Fig. 2 turns the airborne-compute choice into a measured trade-off. On Ethernet, x86, Jetson, and Pi 5 split DUs reach 99.4/22.6, 87.9/18.1, and 61.8/15.4 Mb/s DL/UL. Jetson therefore preserves 88.4% of x86 DL while moving the DU onto an embedded board; Pi 5 preserves 62.2%. More importantly, the Jetson/x86 ratio remains 87.5–89.0% across all three bearers. Among the tested embedded candidates, Jetson is therefore the strongest performance-preserving choice for the intended airborne DU, while Pi 5 provides a simpler reproducible baseline at a larger throughput cost. The host ranking is the same across Ethernet, Wi-Fi/GRE, and 5G/WireGuard, showing that the ARM penalty is not a single-bearer accident. B. The Cost of Untethering F1

Normalizing each host to its own Ethernet result isolates the transport side of the design. 5G/WireGuard retains 76.7% (x86), 77.1% (Jetson), and 76.4% (Pi 5) of wired DL; WiFi/GRE retains 52.1%, 51.5%, and 66.2%, respectively. Thus, route selection. Delay is therefore reported through location- the 5G/WireGuard penalty is remarkably consistent across very normalized ∆RTT, while bearer substitution remains an end- different DU hosts in this setup. It should not be read as a to-end systems variable including contention, encapsulation, general 5G versus Wi-Fi ranking: the Wi-Fi route is contained, host networking, and the modem/underlay. whereas the RM500Q-GL uses an independent donor gNB.

TABLE V

UL

DL

X 86 M ONOLITHIC –E THERNET S PLIT D IAGNOSTIC E VIDENCE 189.2

mono

26.4 99.4

x86 Eth.

22.6 51.8

x86 Wi-Fi

12.1 76.2

x86 5G

18.9

Pi Eth.

15.4

61.8

Metric

Monolithic

Split Ethernet

DL throughput (Mb/s) UL throughput (Mb/s) Dominant DL MCS Filtered DL BLER F1-U rate at 99.4 Mb/s app. F1-U loss / persistent queue Busiest DU RT thread UHD O/L/U counters PRB/TB observation

189.2 26.4 26 0.27 — — — 0/0/0 full/continuous

99.4 22.6 26 0.28 104.8 Mb/s 0 / none 62% 0/0/0 intermittent gaps / smaller TBs

40.9

Pi Wi-Fi

9.8

The higher post-retune BLER is therefore not a regression: it lies inside the relaxed diagnostic window and is paired with a much higher MCS. This before/after experiment shows why F1 setup and packet flow alone are insufficient health criteria, while avoiding the stronger claim that 0.25–0.35 is optimal for other channels or UEs.

47.2

Pi 5G

12.4 87.9

Jetson Eth.

18.1 45.3

Jetson Wi-Fi

13.5

Jetson 5G

16.6

67.8

0

50

100

150

200

Handset throughput (Mb/s), arithmetic mean, n = 20

Fig. 2. Handset DL/UL throughput across ten configurations (arithmetic mean, n = 20 per setup; 400 observations). TABLE IV R EPEATED BLER-T HRESHOLD I NTERVENTION (n = 20) Metric

Default

Diagnostic retune

DL target window DL throughput (Mb/s) Filtered DL BLER Dominant MCS (range)

0.05–0.15 23.4 0.22 3 (2–4)

0.25–0.35 99.4 0.28 26 (25–27)

Rather, it quantifies the cost of replacing the tethered reference with the actual untethered paths available to this testbed. UL follows the same broad host ordering but in a narrower dynamic range. This direction asymmetry matters later: x86 monolithic-to-split DL drops 47.5%, whereas UL drops only 14.4%. Treating “the split penalty” as one scalar would hide that scheduler/traffic-direction effect. C. A Hidden Failure: Link Adaptation Collapses While F1 Looks Healthy In the initial x86 Ethernet split state, F1 and UE attachment remain healthy, but the mean DL is 23.4 Mb/s. OAI tracks an exponentially filtered BLER, bbk = 0.9bbk−1 + 0.1bk , (1) and adapts MCS against configured lower/upper bounds [16]. With the default DL window 0.05–0.15, mean measured BLER is 0.22, above the upper bound, and dominant MCS collapses to 3 (2–4). After observing this state, we choose 0.25–0.35 as a diagnostic DL window that brackets the measured operating BLER; it is not the result of an optimization sweep and is not proposed as a universal target. Changing only the BLER thresholds (DL 0.25–0.35, UL 0.15–0.35) raises dominant MCS to 26 (25–27), mean measured BLER to 0.28, and mean DL to 99.4 Mb/s, a 4.25× gain. Radio attenuation, BWP, TDD profile, UE, F1 bearer, and traffic generator are unchanged.

D. Residual Monolithic–Split Gap The x86 monolithic reference reaches mean DL of 189.2 Mb/s versus 99.4 Mb/s for the retuned Ethernet split, a 47.5% reduction; mean UL falls only 14.4% (26.4 to 22.6 Mb/s). We compare against the repaired split state specifically so the default BLER collapse is not mistaken for the explanation of this residual gap. The measured radio operating point is nearly identical (MCS 26; BLER 0.27/0.28). Split F1-U carries 104.8 Mb/s, 5.4% above application throughput, with no observed loss or persistent queue; the busiest DU real-time thread is 62%, and UHD reports no O/L/U events. RF-quality collapse, Ethernet capacity, persistent F1-U backlog, and sustained gross CPU saturation are therefore poor primary explanations. The remaining observed discriminator is scheduling occupancy: monolithic execution allocates the full 106-PRB budget on each active DL slot, whereas split execution shows inter-slot gaps and smaller TBs. The current logs do not retain a repeated gap-frequency or TB-size distribution, so this evidence is qualitative. It narrows the likely cause to split-path scheduling/polling/timing behavior but does not distinguish F1 arrival jitter from internal OAI producer–consumer cadence or establish a software root cause. E. Airborne Payload, PWS over F1, and Service Validation The performance numbers matter because they attach to a concrete payload. For the validated Jetson configuration, the board, B210 with access antennas, and RM500Q-GL modem kit total 657.4 g and draw approximately 28 W under sustained traffic. Adding a 100-g integration allowance gives 757.4 g. We do not convert 28 W into flight time because battery voltage, propulsion load, regulator efficiency, cooling, and airframe are aircraft-specific; the measurement is instead the electrical budget that a flight designer must reserve for the cellular payload. Public-warning delivery is a distinct software contribution and a direct emergency-response requirement. A temporary cell deployed above a disaster zone should be able to broadcast safety instructions as soon as coverage is available; PWS is

TABLE VI M EASURED UAV-O RIENTED E LECTRONICS PAYLOAD Item / metric

Measured value

Jetson Orin Nano board USRP B210 + access antennas RM500Q-GL modem kit + antennas

151.4 g 217.3 g 288.7 g

Core electronics mass Integration allowance (+100 g) Sustained-traffic electrical load

657.4 g 757.4 g ∼28 W

well-suited to this role because the warning is cell-broadcast rather than being individually addressed. In prior monolithic OAI work, SIB8 terminates within a single gNB process. In our split gNB, however, the warning originates at the ground CU while the remote DU owns MAC scheduling and the radio. Our patch, therefore, adds the missing F1AP Write-Replace Warning path: the CU packages the PWS system-information container and sends the request over SCTP/F1-C; the DU decodes it and hands SIB8 to MAC for SI scheduling [3]. In the validated single-segment case, the warning traverses CU→F1→DU→SIB8 and is displayed by the commercial handset. The available instrumentation records a 0.13-s CUto-DU network-side event and about 0.8 s handset-visible latency; because these timestamps are not generated from one synchronized clock, we treat them as service-validation intervals, not a stage-by-stage latency decomposition. As a secondary replication check, two DUs remain simultaneously active behind one CU under sustained traffic, retaining 91% and 93% of their individual single-DU baselines. This is a first-step shared-CU feasibility result rather than a scaling study, but together with PWS, it shows that the lightweight remote-cell unit preserves both user data and application-visible broadcast service. A synchronized Pi 5 sample further uses about 1.8 CPU cores and 1.4 GB RAM at 64.8 ◦ C without late/UHD overflow markers after thread pinning. The B210 remains the validated access radio; a future B200mini-class radio could reduce payload mass further, but would require a new integrated power/thermal measurement [17]. V. D ISCUSSION AND D ESIGN I MPLICATIONS

compute and backhaul should be budgeted independently: selecting a faster DU does not remove the penalty of the wireless F1 path, and a good backhaul cannot compensate for an underpowered DU. The BLER experiment adds an operational lesson that matters outside the headline throughput plot. A cell can have F1 established, a registered UE, and working IP traffic while link adaptation has collapsed to MCS 3. The controlled threshold intervention recovers 4.25× DL without changing RF, UE, BWP, TDD, or F1. For a remote or airborne cell, such a failure would be particularly costly because the system would consume flight energy while providing a fraction of its expected capacity. The layered service gates and telemetry are therefore part of the deployment design, not merely debugging convenience. The remaining x86 monolithic–split gap is separate from that BLER failure. Both states use MCS 26 with BLER 0.27/0.28; split Ethernet carries 104.8 Mb/s F1-U at 99.4 Mb/s application throughput, with zero observed F1-U loss/persistent queue, a 62% busiest DU real-time thread, and clean UHD counters. These observations make sustained RF, F1-capacity, queue, or gross CPU saturation poor explanations. The distinguishing trace is intermittent PRB/TB scheduling in split mode versus continuous full-PRB use monolithically. We therefore narrow the likely cause to the split-path scheduling/polling/timing behavior. Quantitative slot-aligned timestamps for F1-U arrival, DU wake-up, grant construction, TB size, PRB occupancy, and HARQ feedback are still required to distinguish network arrival jitter from an internal OAI producer–consumer cadence. The study intentionally stops before claiming flight endurance or universal bearer rankings. We test one n78/106PRB profile, one commercial UE, and specific Wi-Fi and donor-cell routes. Likewise, the diagnostic BLER window was chosen after observing the failure state; it proves the controller mechanism in this setup, not a universal optimum. These boundaries do not weaken the central result: they define a reproducible laboratory baseline from which an airframe designer can trade DU performance, backhaul choice, payload mass, and power without first rebuilding the cellular stack from scratch.

VI. R EPRODUCIBILITY A RTIFACT The measurements give a direct answer to the UAV design question. Keeping the 5GC/CU on the ground avoids repeating To make the UAV-oriented baseline reproducible outside our shared compute on every aircraft; the remaining choice is how lab, the public artifact pins the OAI revision, the published much performance to buy with the computer that does fly. PWS-over-F1 and instrumentation patches, sanitized scenario In our fixed 106-PRB testbed, Jetson loses only 10–12.5% templates, host discovery, MTU/routing setup, Jetson SCTP of x86 DL across the three bearers, while Pi 5 accepts a kernel build, packet-path checks, service gates, and rollback larger performance reduction. Combined with the measured workflow [14], [3], [15]. It also records the operational 657.4-g / 28-W Jetson-based electronics point, this makes the details that are brittle in a real lab: live B210 ownership, the Jetson configuration the most attractive performance-preserving RM500Q-GL donor/access boundary, Ethernet MTU restoraembedded option we tested. This is a testbed-specific design tion, GRE/WireGuard route selection, and detection of stale conclusion, not a claim that one ARM board is universally F1 traffic on management interfaces. Reproduction requires optimal. F1 on the intended interface, UE attachment to the access Untethering the F1 link creates a second, largely separable B210, a working PDU session, and clean return to the Ethernet cost. The 5G/WireGuard path preserves about 76–77% of each baseline. host’s Ethernet DL, whereas the tested Wi-Fi/GRE route is This artifact-first contract is important because several failure lower and more variable. For an aerial system, this means modes in the paper leave processes alive: wrong-interface

F1 can still establish SCTP, and the default BLER state still registers the UE and carries IP traffic. The reproduction target is therefore the layered observable signature (configuration, packet path, radio state, service, and performance), not a successful launch command. VII. C ONCLUSION We built the split-DU testbed around a simple aerial design objective: keep shared 5GC/CU compute on the ground and make the repeated airborne unit as small and reproducible as possible without giving up useful real-radio performance. With commodity hardware, Jetson retains 88.4% of x86 Ethernet DL and 87.5–89.0% across all tested F1 bearers, while the validated Jetson/B210/RM500Q-GL electronics weigh 657.4 g and draw about 28 W. Across 400 repeated measurements, the resulting arithmetic means provide practical design baselines. A controlled BLER intervention recovers a 4.25× hidden throughput collapse, and synchronized mono/split telemetry narrows the remaining split penalty to scheduling/timing behavior rather than a simple RF, F1-capacity, or CPU bottleneck. We also contribute to a public OAI PWS-over-F1 path: a released F1AP Write-Replace Warning patch carries the warning from the ground CU to the remote DU, which broadcasts SIB8 to compatible handsets without per-user phone-number addressing. This directly connects the system objective to the emergency use case: a lightweight cell flown over an affected area can provide an immediate area-wide warning service as well as user data. Two-DU operation further verifies the first-step replication behind the shared ground CU. The result is not only an OAI setup that runs on ARM, but a reproducible remote-cell building block for future UAV experiments where every carried gram and watt matters. R EFERENCES [1] 3GPP, “TS 38.401: NG-RAN; architecture description,” 3rd Generation Partnership Project, Technical Specification, 2025, release 18, version 18.6.0. [Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3219 [2] ——, “TS 38.473: NG-RAN; F1 application protocol (F1AP),” 3rd Generation Partnership Project, Technical Specification, 2026, release 18, version 18.10.0. [Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3260 [3] M. Duboc and A. El Falou, “OAI PWS/SIB8 over F1 CU/DU Patch,” https://github.com/promaaa/oai-cu-du-lab/blob/main/patches/sib8/ oai-pws-sib8-cu-du.patch, 2026, public patch implementing F1AP WriteReplace Warning from CU to DU and DU-side SIB8 scheduling; accessed 2026-08-19. [4] R. Gangula, O. Esrafilian, D. Gesbert, C. Roux, F. Kaltenberger, and R. Knopp, “Flying rebots: First results on an autonomous UAV-based LTE relay using OpenAirInterface,” in Proc. IEEE International Workshop on Signal Processing Advances in Wireless Communications (SPAWC), 2018, pp. 1–5. [5] A. Chakraborty, E. Chai, K. Sundaresan, A. Khojastepour, and S. Rangarajan, “SkyRAN: A self-organizing LTE RAN in the sky,” in Proc. ACM Conference on Emerging Networking Experiments and Technologies (CoNEXT), 2018, pp. 280–292. [6] L. Ferranti, L. Bonati, S. D’Oro, and T. Melodia, “SkyCell: A prototyping platform for 5G aerial base stations,” in Proc. IEEE WoWMoM, 2020, pp. 329–334.

[7] R. Mundlamuri, O. Esrafilian, R. Gangula, R. Kharade, C. Roux, F. Kaltenberger, R. Knopp, and D. Gesbert, “Integrated access and backhaul in 5G with aerial distributed unit using OpenAirInterface,” in Proc. 17th ACM Workshop on Wireless Network Testbeds, Experimental Evaluation and Characterization (WiNTECH), 2023, demo. [Online]. Available: https://www.eurecom.fr/publication/7304 [8] D. T. Bui and L.-N. Tran, “An implementation of multi-user MIMO downlink for O-RAN 5G new radio using OpenAirInterface,” arXiv preprint arXiv:2509.25512, 2025. [Online]. Available: https: //arxiv.org/abs/2509.25512 [9] R. Beurdouche and R. Knopp, “An intensive vRAN deployment with OpenAirInterface,” arXiv preprint arXiv:2605.22638, 2026. [Online]. Available: https://arxiv.org/abs/2605.22638 [10] OpenAirInterface Software Alliance, “OpenAirInterface5G v2.1.0 release notes: ARM compilation through SIMDe,” https://gitlab.eurecom.fr/oai/ openairinterface5g/-/tags/v2.1.0, 2024, accessed: 2026-07-20. [11] SnT/SIGCOM 6GSPACE Lab, “Past and current activities on 5G and 6G NTNs using OAI at the 6GSPACE lab of SnT/SIGCOM,” https://openairinterface.org/wp-content/uploads/2024/03/2024-04-05_ SnT_EURECOM-OAI-NTN-Meeting.pdf, 2024, eURECOM/OAI NTN Meeting, accessed: 2026-07-20. [12] E. Bitsikas and C. Pöpper, “You have been warned: Abusing 5G’s warning and emergency systems,” in Proc. 38th Annual Computer Security Applications Conference (ACSAC), 2022, pp. 561–575. [13] A. Abou Hasna, N. Chendeb, and A. El Falou, “From spoofing to trust: Emergency alerts spoofing testbed and cross-cell verification,” arXiv preprint arXiv:2604.24404, 2026. [Online]. Available: https: //arxiv.org/abs/2604.24404 [14] OAI CU/DU Lab Maintainers, “OAI CU/DU Lab: Reproducible 5G SplitRAN artifact,” https://github.com/promaaa/oai-cu-du-lab, 2026, accessed: 2026-08-13; OAI pin, feature patches, and operator tooling. [15] M. Duboc and A. El Falou, “Jetson Orin Nano custom SCTP kernel and out-of-tree drivers guide,” https://github.com/promaaa/jetson-kernel-sctp, 2026, accessed: 2026-07-20. [16] OpenAirInterface Software Alliance, “OpenAirInterface 5G MAC usage and scheduler documentation,” https://github.com/ OPENAIRINTERFACE/openairinterface5g/blob/develop/doc/MAC/ mac-usage.md, 2024, accessed: 2026-07-20. [17] Ettus Research, “B200/B210/B200mini/B205mini/B206mini hardware and physical specifications,” https://kb.ettus.com/B200/B210/B200mini/ B205mini/B206mini, 2024, accessed: 2026-07-20.

Related documents

• Toward Lightweight Aerial 5G gNBs: Reproducible OAI Testbed on Commodity ARM Platforms#1200658
• HiPEAC Vision 2025: High Performance, Edge and Cloud Computing#1361094
• LLM-Powered Agentic AI for 5G/6G Networks: A Tutorial and Survey on Architectures, Protocols, and Standardization#381705
• MERRA derived hourly time series of GB-aggregated wind power, solar power and demand#286399
• False-CSI Attacks in Power-Domain NOMA for 6G: A Threat Taxonomy and System-Level Impacts#618507