Source-linked AI summary
SL-RFSIM: Enabling Scalable Multi-Hop 5G NR Sidelink Mesh Networking in OpenAirInterface
Simone Pio Candido, Jin Yan, Jérôme Härri
TL;DR
Scalable, reproducible experimentation with multi-user NR sidelink meshes and executable protocol implementations remains limited. SL-RFSIM extends OAI with broker-based peer connectivity and modular services; validation demonstrates mesh routing and identifies software bottlenecks to scalability.
Problem
Scalable experimentation combining multi-user NR sidelink meshes with executable 3GPP protocols remains largely unexplored, leaving no open platform for reproducible evaluation of mesh protocols, relays, and realistic propagation.
Source: §1 · p. 1Method
Results
Experimental validation on SLICES-RI demonstrated BATMAN-adv Layer-2 routing, realistic channel modelling, and scalable multi-user experimentation, while identifying current scalability bottlenecks.
Source: §6 · p. 8Takeaways & Limitations
SL-RFSIM provides a reproducible open-source environment for evaluating wireless mesh networking over 5G NR sidelink.
Source: §6 · p. 8The external reception module provides a configurable parallel estimate for observability; OAI's internal PHY still decides packet reception using real IQ samples.
Source: §4.4 · p. 4
Abstract
from arXiv · showhide
Recent 3GPP releases have extended 5G New Radio (NR) Sidelink (SL) to support device-to-device (D2D) relay and multi-hop capabilities. This paper presents SL-RFSIM, a component-based experimentation framework extending OpenAirInterface (OAI) with scalable multi-hop NR SL capabilities. SL-RFSIM replaces the legacy OAI RF simulator with a broker-based publish/subscribe architecture enabling arbitrary peer-to-peer connectivity while preserving compatibility with the OAI protocol stack. The framework further integrates pluggable mobility, propagation, reception, and monitoring services, and supports Layer-2 mesh networking through BATMAN-adv. Experimental evaluation on the SLICES-RI research infrastructure validates the proposed architecture through representative mesh networking scenarios and identifies the current software bottlenecks limiting scalability. SL-RFSIM provides an open-source foundation for reproducible experimental research on 5G NR SL and future multi-hop cellular mesh networks.
1 Introduction
Multi-hop NR sidelink has growing relevance, but scalable, reproducible experiments with executable 3GPP protocol implementations remain largely unexplored. SL-RFSIM extends OAI with a broker-based framework for multi-hop experimentation and evaluates it in representative mesh scenarios.
1 Introduction
- Scalable experiments combining multi-user NR sidelink meshes with executable 3GPP protocol implementations remain largely unexplored.The paper identifies a resulting lack of an open platform for reproducible evaluation of mesh protocols, relays, and realistic propagation.Source: §1 · p. 1
- SL-RFSIM extends OAI with a broker-based RF simulation architecture for scalable peer-to-peer NR sidelink communication.Its contributions also include extensible mobility, propagation, reception, and monitoring services; BATMAN-adv Layer-2 mesh support; and an open-source platform for reproducible experiments.Source: §1 · p. 1
- The framework is evaluated through representative multi-hop mesh scenarios, with results validating the architecture, demonstrating realistic channel abstraction, and identifying software bottlenecks to scalability.Source: §1 · p. 1
2 Related Work
Existing OAI sidelink implementations, simulation platforms, RF emulation, and mesh-routing protocols offer complementary capabilities, but no single framework integrates them for scalable OAI-based multi-hop mesh experimentation. The related work therefore motivates a composable, reproducible platform combining executable protocols and mesh networking.
2 Related Work
- OAI supports sidelink and relay functionality, but current implementations are mainly intended for point-to-point communication and limited relay scenarios.Source: §2 · p. 1
- 5G-LENA, MoReV2X, link-level simulators, Colosseum, and SLICES-RI address distinct simulation, PHY evaluation, RF emulation, or infrastructure needs.These platforms are not specifically designed for scalable multi-hop NR sidelink experimentation integrated with OAI.Source: §2 · p. 1
- Mesh-routing protocols including AODV, OLSR, and BATMAN-adv generally operate apart from executable 3GPP stacks or are evaluated with abstract simulators.Source: §2 · p. 2
- No existing framework integrates NR sidelink models, realistic RF emulation, wireless simulation, and mesh routing into a composable, reproducible platform for scalable OAI-based mesh networking.Source: §2 · p. 2
3 OpenAirInterface (OAI) Sidelink
OAI provides sidelink channels and procedures, with multi-UE operation requiring scheduling. The section then explains the mesh-relaying approach and why legacy RFSim cannot model multi-UE sidelink meshes.
3.1 OAI 5G NR Sidelink Architecture
- OAI supports PSBCH, PSCCH, and PSSCH and includes sidelink procedures across SDAP, PDCP, RLC, and MAC for two-UE communication.Multi-UE operation requires a scheduler; mode 2(c) uses collision-free TDMA with a coordinating UE statically assigning sidelink subframes.Source: §3.1 · p. 2
3.2 OAI Mesh Architecture
- Because APIs between SRAP and external mesh protocols are missing, the paper delegates relaying to higher-layer protocols and adopts BATMAN-adv for Layer-2 mesh networking.The choice trades SRAP fidelity for immediate availability because BATMAN-adv is available in Linux kernels; the architecture includes an SLC to externally control UE RRC, notably the scheduler.Source: §3.2 · p. 2, Figure 1 · p. 2
3.3 OAI RF Simulator (RFSim)
- Legacy RFSim uses a gNB server and UE clients, so its clients cannot connect directly to model multi-UE sidelink mesh communication.The paper identifies this single-server topology as the reason RFSim cannot be used for sidelink beyond two UEs.Source: §3.3 · p. 2, Figure 2 · p. 2
4 OAI SL-RFSIM
SL-RFSIM is proposed as a replacement for legacy RFSim in OAI sidelink experiments that need meshed connectivity. Its broker-based, modular architecture connects UEs and supporting services, with containerized components and APIs for dynamic experiment configuration.
4 OAI SL-RFSIM
- SL-RFSIM is designed to extend RFSim for experiments requiring many UEs to model sidelink scheduling or relaying.Source: §4 · p. 2
4.1 Architecture and API Specification
- A broker-orchestrated publish/subscribe architecture supports full-mesh UE connectivity and connects mobility, propagation, reception, and monitoring modules.Source: §4.1 · p. 2
- The Docker design runs the broker and modules in interconnected containers, with UEs added as new containers connected to the broker.Source: §4.1 · pp. 2–3
- APIs allow modules to be adjusted dynamically and UEs to be on- or off-boarded; joining UEs trigger mobility initialization automatically.A Sync-Ref UE remains necessary under the 3GPP sidelink specification, but SL-RFSIM treats it like any other UE.Source: §4.1 · p. 3
4.2 Mobility Module
The mobility module configures each UE’s position, heading, and velocity, with updates every 100 ms. It supports several mobility models and can switch models at runtime without restarting processes.
4.2 Mobility Module
- UE positions, headings, and velocities update every 100 ms, with support for Random Waypoint, Random Walk, Gauss-Markov, and Reference Point Group Mobility models.The module is based on the pymobility library.Source: §4.2 · p. 3
- The experiments use Random Waypoint, where UEs choose leg speeds uniformly within configured bounds and pause uniformly up to a configured maximum at each waypoint.Scenario parameters include the bounding-box side length, minimum and maximum speeds, and maximum pause time.Source: §4.2 · p. 3
- The mobility module runs separately from OAI and communicates with the broker using ZMQ messages with JSON payloads.Its separation permits future integration of other mobility models or domain-specific tools without redesigning the broker.Source: §4.2 · p. 3
4.3 Propagation Module
SL-RFSIM provides five propagation models with probabilistic LOS/NLOS selection, alongside configurable link-specific attenuation or blocking. The models cover free-space, vehicle, indoor, and rural settings.
4.3 Propagation Module
- Five 3GPP-compliant path-loss models incorporate probabilistic LOS/NLOS selection, while links can also be assigned arbitrary attenuation or fully blocked.The propagation module runs independently and returns path loss, background noise, and Doppler shift for a transmitter–receiver link; it recalculates conditions on each call.Source: §4.3 · p. 3
- Free Space follows ITU-R P.525-3 and serves as a distance-only theoretical baseline without environmental effects.It has no LOS/NLOS selection.Source: §4.3 · p. 3
- Urban V2V selects among LOS, vehicle-blocked NLOSv, and building-blocked NLOS states probabilistically; NLOSv loss depends on the relative heights of the transmitter, receiver, and blocking vehicle.Source: §4.3 · p. 3
- Highway V2V uses Urban V2V path-loss expressions but a different LOS-probability curve, which decays gradually beyond 475 m [23].It uses the same NLOSv model as Urban V2V.Source: §4.3 · p. 3
- Indoor InH applies a piecewise exponential LOS probability over 1–150 m and constrains NLOS loss to be at least the LOS loss.Source: §4.3 · p. 3
- Rural propagation uses the ECC Report 68 three-segment formula, parameterized for vehicle-height antennas and independently validated [16].Source: §4.3 · p. 3
4.4 Reception Module
The reception module estimates reception probability from channel conditions through a staged SNR-to-BLER pipeline. These estimates provide observability, while actual packet reception remains within OAI’s PHY layer.
4.4 Reception Module
- Actual packet reception remains within OAI’s PHY layer; the external reception module provides a configurable parallel estimate for observability.OAI UEs lack hooks for sending channel-quality metrics or reception conditions to external entities, and the module is designed for possible future use in system-level reception decisions.Source: §4.4 · p. 4
- The module estimates BLER from SNR using 6,188 BLER-versus-SNR curves in the UWICORE NR V2X SL dataset, then computes reception probability as 1 − BLER.The dataset follows 3GPP Rel. 16 specifications.Source: §4.4 · p. 4
- The six-step pipeline applies a Doppler ceiling check and SNR penalty, maps SNR to CQI and CQI to MCS, looks up BLER, then computes reception probability.Above the speed-dependent MCS ceiling, the procedure sets BLER to 1 and reception probability to 0; below it, residual Doppler is modelled as an SNR penalty.Source: §4.4 · p. 4
- When using OAI fallback tables, the pipeline applies a fixed 2.0 dB LDPC correction, but skips it for UWICORE, whose measured coded transmissions already reflect that gain.Source: §4.4 · p. 4
- Effective SNR maps to CQI using the 3GPP TS 38.214 table used by OAI, then CQI and MCS indices are matched between OAI and UWICORE for the BLER lookup.Source: §4.4 · p. 4, Table 3 · p. 4
4.5 Broker
The broker coordinates per-UE-pair channel processing and forwarding while leaving actual reception to OAI’s PHY. The section describes path-loss scaling, Doppler rotation, and analytical SNR estimation, including a Doppler experiment showing effects on PSBCH success.
4.5 Broker
- The broker tracks connected UEs and pairwise channel conditions, processes forwarded IQ samples per UE pair, and forwards them to receivers; actual reception stays within OAI’s PHY.It caches UE positions every 100 ms, queries propagation for path loss and Doppler, and queries reception estimates for monitoring.Source: §4.5 · p. 4
4.5.1 Differential Path-loss Scaling and I/Q Quantization.
- The broker applies path-loss scaling to IQ samples using the Minimum Coupling Loss convention to avoid numerical truncation to zero at short range.Empirical calibration found an 80 dB MCL best aligned IQ amplitude with theoretical SNR, minimizing divergence between the OAI decoder and UWICORE tables.Source: §4.5.1 · pp. 4–5
4.5.2 OFDM-Aware Doppler Phase Rotation.
- In a 200 m highway link, PSBCH success is ≈100% without channel effects, ≈73% with Doppler off, and ≈81% at 𝑓𝑑≈1 Hz; PSCCH/PSSCH decoding remains largely unaffected.Phase resets every 2 ms because OAI’s sidelink RFSim lacks pilot-based CFO correction on reception; without resets, drift breaks synchronization within a few hundred milliseconds.Source: §4.5.2 · p. 5
4.5.3 Analytical SNR Estimation.
- The broker’s analytical SNR is derived from path loss, using transmit power of 23 dBm, a noise density of −174 dBm/Hz, and operational bandwidth.Source: §4.5.3 · p. 5
4.6 Grafana & InfluxDB Monitoring Stack
Grafana and InfluxDB provide a decoupled monitoring path for SL-RFSIM, with the broker publishing KPIs for dashboard display. The path-loss value used for reception estimates is deliberately not MCL-clipped.
4.6 Grafana & InfluxDB Monitoring Stack
- An Exporter polls modules every second, writes metrics to InfluxDB, and Grafana reads them through 5 s Flux queries.Grafana reads only InfluxDB; it does not query OAI or the broker directly.Source: §4.6 · p. 5
- The polling-based monitoring stack stays decoupled from OAI, while the broker periodically publishes monitoring KPIs to InfluxDB.Source: §4.6 · p. 5
- Reception estimates use unmodified path loss rather than the MCL-clipped value, avoiding inflated SNR.Source: §4.6 · p. 5
5 Experimentation & Validation
Validation on SLICES-RI exercises SL-RFSIM across reception checks, static and mobile mesh topologies, and full-mesh scalability tests. The experiments demonstrate multi-hop routing and expose software bottlenecks that constrain the tested scale.
5 Experimentation & Validation
- Validation ran on the SLICES-RI OpenXGLab node at EURECOM, using an x86_64 cluster with 8 Xeon Gold CPU cores and 8 GB RAM.Source: §5 · p. 5
5.1 Cluster Access & Scenario Configuration
- Python scripts configure mobility, propagation, UE count, and mesh links, while ready-to-use Docker containers avoid recompiling OAI for each UE.Broker latency characterization and direct comparison with legacy client-server RFSim were left to future work.Source: §5.1 · pp. 5–6
5.2 Grafana Dashboard
- The dashboard presents UE positions and link states, per-link channel and reception metrics, PSCCH reception-lock comparisons, and distance/LOS panels.Source: §5.2 · p. 6
5.3 Reception Module Validation
- System-level and link-level reception agreement was 99.1% at 1000 m and 98.7% at 5000 m, supporting the module's use for monitoring.At 5000 m, channel variability was σ_prx = 14.9%.Source: §5.3 · p. 6, Table 4 · p. 6
5.4 Multi-hop Line Topology
- With direct UE1–UE2 paths blocked, the UE1–UE0 and UE0–UE2 links each measured 150 m with 100% reception probability; BATMAN-adv provided end-to-end Layer-2 multi-hop relaying through UE0.Source: §5.4 · pp. 6–7
5.5 Multi-hop Mesh Star Topology
- In the five-UE star, every peripheral UE reached every other peripheral UE exclusively through the central Sync-Ref, with TQ values from 1 to 51 across ten routes.Source: §5.5 · p. 7, Table 6 · p. 7
5.6 Multi-hop Mobile Topology
- Across mobile-run snapshots, every observed route was direct to Sync-Ref or relayed through it; no peer-to-peer route via another peripheral UE appeared.Changing positions formed and broke links over time, with SNR fluctuations visible in the dashboard.Source: §5.6 · p. 7, Table 6 · p. 7
5.7 Scalability Analysis
- Up to 7 UEs, the full stack is stable; beyond that, PSSCH and BATMAN-adv become unstable from scheduler slot exhaustion, while PSBCH synchronization persists to 15 UEs on Xeon and partly to 17–19 across platforms.SL-RFSIM supports up to 15 UEs and 210 directional links, compared with RFSim's 100 links; identified bottlenecks include synchronous broker calls, per-peer buffer memory, and multiplexing control and data packets.Source: §5.7 · pp. 7–8, Table 7 · p. 8
6 Conclusion
The paper presents SL-RFSIM, a broker-based OAI extension for multi-hop 5G NR sidelink experimentation. Validation on SLICES-RI demonstrated mesh and channel-model integration, while identifying current scalability bottlenecks.
6 Conclusion
- SL-RFSIM replaces conventional RFSim's client-server architecture with a broker-based publish/subscribe framework for arbitrary peer-to-peer connectivity while preserving OAI compatibility.It integrates modular mobility, propagation, reception, and monitoring services for reproducible wireless mesh experimentation.Source: §6 · p. 8
- SLICES-RI experiments demonstrated BATMAN-adv Layer-2 routing, realistic channel modelling, and multi-user experimentation, while identifying software bottlenecks that guide future development.Source: §6 · p. 8
- Future work includes standardized Rel. 19 sidelink relaying, distributed sidelink scheduling, richer mobility models, O-RAN monitoring interfaces, and larger deployments with additional mesh routing protocols.Source: §6 · p. 8