As RAN research moves toward AI-native scheduling, network slicing, digital twins, NTN and 6G, the ability to run realistic multi-UE experiments becomes increasingly important. The challenge is not simply to connect a few software UEs to a gNB. The real requirement is a repeatable environment where many UEs compete for radio resources, generate different traffic patterns and expose the RAN to conditions closer to a real network.
That is the direction of the latest work around OCUDU-RAN and the OpenAirInterface rfsimulator. The new implementation integrates OAI's native rfsimulator directly into OCUDU-RAN, and has been validated with up to 50 concurrent software UEs connected to a single OCUDU gNB on one machine.
From multi-UE testbed to a scalable radio interface
Our earlier multi-UE environment used multiple OAI software UEs connected to a single OCUDU gNB through the ZeroMQ radio interface. A Python IQ-superposition proxy created the shared-air-interface behaviour: downlink IQ was replicated toward each UE, uplink IQ from multiple UEs was combined sample by sample, Linux network namespaces isolated the UE data paths, and a test harness managed provisioning, attachment, traffic generation and monitoring.
That approach provided a practical software-based alternative to commercial UE simulators and larger hardware-dependent test environments. It also became a useful foundation for experiments such as end-to-end network slicing, where multiple UEs could be placed in different slices and used to evaluate slice-aware scheduling across the RAN and core.
But the architecture had an important limitation. The multi-UE capability was being created around the radio interface, rather than being part of the radio interface itself. The next step was therefore to bring multi-peer support directly into OCUDU-RAN.
Integrating OAI rfsimulator into OCUDU-RAN
OpenAirInterface already provides an rfsimulator designed to work with multiple connected peers. Instead of creating another simulator or maintaining a separate implementation, the OAI rfsimulator has now been integrated directly into OCUDU-RAN, as a native OCUDU radio driver alongside the existing UHD, ZeroMQ and Sidekiq drivers.
The integration uses OCUDU's baseband_gateway interface while retaining the OAI rfsimulator's existing wire protocol, peer-management behaviour and sample-processing logic. A lightweight compatibility layer bridges the OCUDU and OAI environments, allowing the simulator source to be compiled as part of the OCUDU tree without requiring a separate OAI source checkout.
The driver is enabled at build time with cmake -DENABLE_RFSIM=ON. The gNB then listens on a single rfsimulator port, with multiple OAI UEs connecting directly to it.
One gNB, many UE peers
The biggest architectural difference compared with the earlier ZeroMQ design is the socket model. The ZeroMQ driver uses a REQ/REP pattern designed around a one-to-one relationship. The rfsimulator instead uses a listening socket and an accept loop, and each connected UE receives its own peer state, receive buffers, timestamp handling and connection context.
During every slot, the received contributions from the connected UEs are combined before being delivered to the gNB. This means multi-user behaviour is no longer created by an external proxy: it becomes part of the radio simulation path itself.
That matters as the UE count increases, because the gNB begins to experience the types of resource competition that are important in real deployments, including scheduler contention, HARQ activity, PUCCH pressure, admission behaviour and per-UE resource allocation.
Making 50 software UEs practical
Scaling to 50 UEs required more than simply supporting additional socket connections. The blocking behaviour of rfsimulator had to be reflected across the OCUDU execution path.
Parts of the existing RAN implementation previously checked explicitly for the ZeroMQ driver when selecting lower-PHY execution behaviour. That logic has been generalised into a common blocking-radio-driver check, which is useful beyond rfsimulator itself: future socket-backed radio drivers can use the same execution behaviour without introducing new driver-specific conditions throughout the RAN code.
The lower-PHY executor path was also updated so the required worker can be created when it is not already present, while preserving an existing executor when available.
Automating the multi-UE experiment
A dedicated test harness automates the complete multi-UE environment. Each UE runs inside its own Linux network namespace, which prevents the tunnel interfaces created by OAI from colliding when many UEs run on the same host.
The harness launches UEs in a controlled sequence, validates attachment, runs concurrent uplink and downlink traffic, monitors individual UEs, collects per-UE results, and isolates failed attachments.
That last point is particularly useful: a problem with one UE does not invalidate the complete test run. The objective is not just to demonstrate that 50 UEs can connect, but to create a platform where RAN behaviour at scale can be tested repeatedly and reproducibly.
Performance optimisation at multi-UE scale
As the number of connected peers increases, sample processing becomes a significant part of the workload. Several optimisations were introduced.
On the transmit path, multiple writes for each sample block were replaced with a single writev() operation, reducing the number of system calls needed to transmit the header and antenna samples. TCP_NODELAY was enabled to avoid unnecessary delay in the lockstep simulation path.
The largest optimisation came from the receive path. For the common 1x1 configuration, the first received contribution does not need to be accumulated into an intermediate buffer, because its mixing coefficient is effectively one. The new fast path places the first contribution directly into the output buffer and accumulates only subsequent peer contributions.
The measured impact was significant. Approximately 45% of the performance improvement came from that optimisation, with additional lower-PHY parallelism contributing approximately 7%. Across the complete set of changes, aggregate downlink throughput at eight UEs increased from 67.05 Mbps to 106.25 Mbps, an improvement of roughly 58%.
What happens as the cell fills?
The environment was evaluated at 8, 16 and 50 UEs using a 40 MHz configuration, against both an OAI CN5G core and SD-Core.
| Metric |  OAI CN5G |  SD-Core | ||||
|---|---|---|---|---|---|---|
| 8 UEs | 16 UEs | 50 UEs | 8 UEs | 16 UEs | 50 UEs | |
| Attached | 8 / 8 | 16 / 16 | 50 / 50 | 8 / 8 | 16 / 16 | 50 / 50 |
| DL aggregate | 106.25 Mbps | 54.33 Mbps | 16.40 Mbps | 97.36 Mbps | 51.13 Mbps | 15.12 Mbps |
| DL per UE | 13.28 | 3.40 | 0.328 | 12.170 | 3.196 | 0.308 |
| UL aggregate | 44.94 Mbps | 39.68 Mbps | 17.27 Mbps | 49.02 Mbps | 37.34 Mbps | 16.80 Mbps |
| Real-time factor | 1.0487x | 0.532x | 0.110x | 1.0743x | 0.5288x | 0.1448x |
The lower measured throughput at higher UE counts needs to be interpreted together with the simulator's real-time factor. A factor of 1.0 means simulated time advances at approximately the same rate as wall-clock time. At 50 UEs the measured factor of 0.110x means simulation time is progressing roughly nine times slower than real time.
When throughput is normalised using that factor, the effective capacity remains broadly consistent at approximately 96.7 to 106 Mbps across the tested UE counts and both cores.
This tells us something important about the current boundary of the system. UE connectivity scales to 50 users, while host-side simulation processing increasingly becomes the limiting factor. The bottleneck is therefore primarily the processing required to serialise and handle the radio sample streams, rather than an inability of the RAN to maintain the connected UEs.
Why this matters for AI-RAN
AI-RAN research needs more than offline datasets. To evaluate intelligent scheduling or RAN optimisation properly, algorithms eventually need to interact with a functioning RAN stack under changing traffic and resource conditions.
A scalable software-based multi-UE environment provides exactly that. Multiple UEs can simultaneously create different traffic loads while the scheduler has to make real resource-allocation decisions, creating a foundation for evaluating AI-assisted scheduling, congestion optimisation, resource-allocation algorithms, admission strategies and multi-UE performance behaviour.
Instead of testing an algorithm only against an abstract simulation model, developers can move closer to evaluating it inside an actual RAN implementation.
A foundation for network slicing
Network slicing becomes much more meaningful when several UEs are competing for the same radio resources. A scalable multi-UE environment allows different groups of UEs to be associated with different slices and traffic profiles, so researchers can study how the network behaves as traffic demand changes, slices compete for resources, scheduler policies change and UE populations increase.
The earlier OCUDU multi-UE environment had already been used as a foundation for slice-aware experiments. Integrating multi-UE capability directly into the radio simulation layer makes that experimentation more scalable and architecturally cleaner.
Toward digital twins, NTN and 6G experimentation
The value of this environment extends beyond conventional 5G testing. Software-based multi-UE RAN simulation provides a building block for several emerging research areas:
- AI-RAN: testing intelligent scheduling and optimisation against real RAN behaviour.
- Network slicing: studying resource competition and service differentiation across multiple UE groups.
- Digital twins: creating repeatable software representations of RAN behaviour that can be driven under different traffic and network conditions.
- NTN: providing a flexible environment where future timing, scheduling and networking concepts can be integrated and evaluated.
- 6G experimentation: allowing new algorithms and architectures to move beyond theoretical evaluation and interact with an actual network stack.
The importance of the platform is therefore not simply that it can simulate more UEs. The bigger objective is to reduce the distance between a research idea and a working network experiment.
From idea to network experiment
A useful 6G research platform should make it possible to move through a complete experimentation cycle:
Idea to algorithm to RAN implementation to multi-UE experiment to measurable network behaviour.
That is the direction in which OCUDU-RAN is evolving. With the OAI rfsimulator integrated directly into the radio layer and up to 50 concurrent software UEs validated against a single OCUDU gNB, the platform now provides a stronger foundation for scalable RAN experimentation.
The next challenge is not simply supporting more connected UEs. It is continuing to improve simulation performance, scale the environment further, and make it easier for researchers and developers to evaluate the technologies that will shape AI-RAN and 6G.
OCUDU-RAN rfsimulator is therefore more than a multi-UE simulator. It is becoming a software-based experimentation foundation for building, integrating and validating the next generation of RAN technologies.
The full deployment guide, with build instructions, harness options and measured results, is in the documentation: rfsimulator Multi-UE Testbed.