MIRAGE: A GPU-Accelerated IQ-Level Channel Emulator for Real-Time Wireless Digital Twins

This work has been submitted to the IEEE for possible publication.

1

MIRAGE: A GPU-Accelerated IQ-Level Channel Emulator for Real-Time Wireless Digital Twins

arXiv:2610.38918v1 [cs.NI] 28 Oct 2026

Ali Saeizadeh, Angelo Feraudo, Avaneeth Anil, Leonardo Bonati, Pedram Johari, and Tommaso Melodia Abstract—Wireless digital twins enable network policies to be evaluated before deployment, but reproducing channel effects within a running protocol stack requires continuous waveform processing under strict timing constraints. We present M IRAGE, a GPU-accelerated channel emulator that applies propagation effects directly to in-phase and quadrature samples exchanged by software 5G New Radio stacks. M IRAGE combines batched multiuser, multiantenna filtering with timestamped shared-memory transport and radio-driver integrations for OpenAirInterface and OCUDU. External propagation models supply channel responses asynchronously, while versioned buffers ensure consistent coefficients within each processing interval. Experiments on one NVIDIA H100 GPU evaluate waveform accuracy, processing time, channel updates, and full-stack traffic delivery. At 61.44 million samples per second, eight single-antenna links, four two-by-two links, and one four-by-four link meet the tested 0.5 ms bidirectional processing criterion. Waveform errors remain within one integer quantization step per component, with no mixed coefficient versions across 16.7 million analyzed slots. Integration with the X5G testbed enables slice resource allocations to be evaluated before deployment. Both evaluated slices ultimately satisfy their throughput caps, requiring one physical reconfiguration under line-of-sight conditions and four under non-line-of-sight conditions. These results demonstrate full-stack policy evaluation and expose prediction errors affecting transfer to a physical network. Index Terms—Channel emulation, digital twins, GPU computing, mobile networks, software-defined radio.

✦

1

I NTRODUCTION

Generative AI can reduce the effort required to translate ideas into network implementations and control policies [1]. As implementation becomes easier, verification and validation become increasingly important before deployment [2]. In Radio Access Networks (RANs), testing must check more than software correctness. It must also assess protocol interactions, radio timing, and behavior under different traffic and channel conditions. Testing changes directly on a live network can affect users, while wireless variability complicates reproducible comparisons [3]. Wireless Digital Twins (DTs) provide a controlled environment for assessing these changes before applying them to the physical network [4], [5]. Their value depends on reproducing the channel conditions and system behavior relevant to the experiment [6]. To support this evaluation, we focus on implementation changes and control policies whose effects depend on waveform reception and protocol behavior. We adopt three design requirements for the twin. First, full-stack fidelity: the twin should execute the protocol-stack components under evaluation and retain interactions involving HARQ retransmissions, link adaptation, RLC segmentation, and scheduling under contention. Second, IQ-level channel application: channel effects should be applied directly to the baseband In-phase and Quadrature (IQ) waveform, allowing multipath propagation and frequency-selective fading to affect signal reception and the resulting Channel Quality • •

The authors are with the Institute for Intelligent Networked Systems, Northeastern University, Boston, MA, U.S.A. E-mail: {saeizadeh.a, a.feraudo, lnu.avan, l.bonati, p.johari, melodia}@northeastern.edu. This work is supported by the National Telecommunications and Information Administration (NTIA)’s Public Wireless Supply Chain Innovation Fund (PWSCIF), Award No. 25-60-IF011.

Information (CQI), Block Error Rate (BLER), and protocol behavior. Fidelity additionally requires validation of the channel model and its application to the waveform [6], [7]. Third, real-time operation and state exchange: the twin should sustain the timing requirements of the radio stack while exchanging relevant state and control information with the physical RAN. These requirements involve distinct timing constraints. IQ processing follows the configured sample rate and NR slot duration, which depends on the subcarrier spacing (SCS) [8]. Sustaining this processing requires coordination among channel computation, buffering, and protocol-stack execution. Channel updates follow changes in the propagation environment, whereas monitoring and control exchanges follow the needs of the control task and can use O-RAN interfaces [9]. Existing platforms address these requirements through different trade-offs. Hardware-based emulators support real-time, signal-level experimentation using dedicated infrastructure [10], [11], [12]. Software platforms offer greater deployment flexibility, but their channel representation and execution model determine whether they exercise waveform reception and preserve radio timing [13], [14], [15], [16], [17], [18]. The design problem is to coordinate multi-link, multi-antenna channel computation with continuous stack execution while external channel responses change asynchronously. Batching reduces GPU dispatch overhead, but the processing path must also preserve sample ordering and use complete coefficient versions. Addressing these requirements together motivates the transport, computation, and update mechanisms developed here. Section 2 examines the closest approaches in detail. Real-time IQ-level channel emulation requires process-

2

× J instances

Physical deployment

Digital twin instance 1

Broker

Software gNB

gNB

Instance configuration

OAI 5G NR stack Config. & KPMs

RU driver

Control decision

Physical medium

xApp: KPM collection

UE 2

···

DT metrics & candidate settings

Metrics

IQ samples

UE 1

Config. inputs

OAI / OCUDU 5G NR stack gpuemu radio driver Timestamped IQ samples

Controls M IRAGE GPU channel emulator CFRs (Redis)

UE K

xApp: PRB slice management

External channel model (Sionna RT)

UE 1

RAN Intelligent Controller (RIC)

UE 2

xApp: KPM collection

···

UE K

xApp: PRB slice management

Fig. 1. Wireless digital twin architecture with J instances and K UEs per instance. M IRAGE applies channel responses to timestamped IQ samples between software radio stacks. An external channel-model server delivers CFRs through Redis, independently of IQ processing. The broker coordinates configuration, measurements, and candidate settings; monitoring and control requests use the RIC/xApps and E2 paths shown by dashed arrows. Broker arrows denote logical information exchanges. The depicted monitoring and control integration is evaluated with OAI. The 5G cores are omitted for clarity.

ing continuous sample streams within the timing budget of the radio stack. For K User Equipments (UEs), L channel taps, and Nslot samples per slot, direct time-domain convolution requires O(Kntx nrx LNslot ) operations per slot, where ntx and nrx denote the numbers of transmit and receive antennas per link. The sample count per slot depends on the sampling rate fs and the slot timing associated with the configured SCS. The processing cost therefore grows with the number of links, channel taps, and antenna pairs, making real-time execution increasingly demanding under multi-UE Multiple Input, Multiple Output (MIMO) operation. Recent GPU-based massive-MIMO systems show that execution granularity and orchestration affect processing latency and throughput [19]. For channel emulation, the operating range consequently depends on channel computation, data movement, and coordination with the radio stack; concurrent DT instances add competition for shared resources. This work. We present M IRAGE (Multi-instance IQlevel Real-time Accelerated GPU Emulator), a GPU-accelerated channel emulator for full-stack wireless DTs. The core contribution is an integrated processing path that batches perlink SISO/MIMO filtering, exchanges timestamped IQ samples with software 5G NR stacks through stack-specific radio drivers, and applies complete channel-response versions while external models produce updates asynchronously. As shown in Fig. 1, a broker couples the resulting software replicas to a physical RAN through state and control exchanges. This architecture supports evaluation of network changes under site-specific channel conditions before selected configurations are applied to the physical deployment.

1.1

Contributions •

•

•

Batched GPU channel emulation integrated with a full 5G stack. We design and implement a frequency-domain IQ-level channel emulator supporting per-UE Single Input, Single Output (SISO) and MIMO channels. Batched GPU processing and shared-memory IQ transport connect the emulator to OpenAirInterface (OAI) and OCUDU through radio-driver plugins, requiring no changes above the device-driver interface. OCUDU integration reuses the emulator and OAI UE source unchanged. We evaluate processing latency, signal fidelity, and end-to-end throughput under multi-UE and multiantenna operation with OAI, and validate OCUDU interoperability in SISO operation. Consistent asynchronous channel updates. We separate external channel generation from IQ processing through a common Channel Frequency Response (CFR) interface and versioned GPU buffers. Each processing interval uses a complete coefficient version for each link and direction while subsequent responses are uploaded asynchronously. We validate update consistency and measure the delay before new responses are first used. Concurrent full-stack instances and their operating limits. We implement isolated DT instances, each comprising a Next Generation Node Base (gNB), UEs, a GPU channel emulator, and a 5G core. We evaluate up to four concurrent instances sharing one NVIDIA H100 GPU and measure traffic delivery and radio-clock progression relative to wall time under a controlled offered load. The evaluation distinguishes

3

TABLE 1 Architectural comparison of wireless emulation platforms and their cited implementations. Platform

Channel processing

Stack integration

Colosseum [10] AODT [20] 5G-EMANE [13] Chronos [14] OAI rfsim [15] OAI vrtsim [21] OWDT [16] Tiny-Twin [17] Sionna Research Kit [22] ACHEM [18]

FPGA signal-level emulation Scene-based propagation; GPU simulation Abstracted PHY behavior Abstracted PHY; virtualized time Optional channel models; CPU-paced execution Built-in models or external CIRs; adjustable pacing Sionna RT channels applied through OAI CPU time-varying multi-tap filtering CUDA SISO filtering; file or streamed CIRs IQ impairments; MIMO and mobility

SDR-based radio nodes Integrated RAN simulation environment Cellular stack with EMANE FAPI MAC–PHY interface TCP radio-sample interface Shared-memory interface; one gNB/UE pair OAI stack with Sionna RT Full 5G stack with per-UE channels Channel plugin within OAI gNB Virtual USRP interface for UHD applications

M IRAGE

Batched GPU SISO/MIMO filtering; versioned CFR up- OAI and OCUDU radio drivers; timestamped dates shared-memory IQ

•

2

successful traffic delivery from real-time execution and characterizes the effects of CPU allocation and concurrent execution on the shared host. Closed-loop evaluation with a physical RAN testbed. We integrate M IRAGE with the X5G testbed through a broker that exchanges network state and control information between the physical deployment and its digital twin. Using site-specific channels and corresponding radio configurations, we evaluate xApp-driven slice Physical Resource Block (PRB) allocation in the twin before applying selected quotas to the physical network. The experiments assess throughput agreement and control outcomes under line-of-sight (LoS) and non-line-of-sight (NLoS) conditions, showing how prediction errors affect the need for subsequent physical reconfiguration.

R ELATED W ORK

We review wireless emulation platforms, channel-modeling methods, and mechanisms for coupling digital twins to physical networks. Table 1 summarizes the platform architectures. 2.1

Hardware-Based and Integrated Platforms

Colosseum [10] combines Universal Software Radio Peripheral (USRP) nodes with an Field Programmable Gate Array (FPGA) channel emulator, while commercial systems [11], [12] provide dedicated channel-emulation appliances. Xie et al. [23] present an 80-channel bidirectional transceiver and baseband platform for massive-MIMO emulation. These systems support signal-level experiments but require dedicated radio and emulation hardware. NVIDIA’s Aerial Omniverse Digital Twin (AODT) [20] instead combines scene-based propagation with GPU-accelerated RAN simulation. Our work targets a software channel emulator connected to an existing protocol stack through its radiodriver interface. 2.2

Platforms with Abstracted PHY Processing

5G-EMANE [13] and Chronos [14] reduce computation by abstracting waveform-level physical layer (PHY) processing. Chronos combines a Functional Application Platform

Interface (FAPI) MAC–PHY interface [24] with virtualized time for cloud-based experiments. Such abstractions support larger simulated networks, but do not exercise receiver processing on channel-impaired IQ samples, which is central to our evaluation target.

2.3

Full-Stack IQ-Level Emulation

The OAI rfsim replaces the radio driver with TCP-based IQ exchange and optional channel modeling; its execution can run faster or slower than wall-clock time [15]. VRTSIM uses shared-memory IQ exchange with a configurable timescale and supports built-in channel models and external CIRs through its taps_client interface [21]. The cited VRTSIM implementation documents a one-gNB/one-UE limit. Thus, shared-memory transport and external channel injection are existing capabilities; our contribution concerns their integration with batched multi-link GPU processing and coefficient-consistency mechanisms. The srsRAN 4G ZeroMQ interface similarly provides radio-sample transport that can be combined with external processing [25]. The Open Wireless Digital Twin (OWDT) [16] couples OAI with Sionna RT for site-specific mobility emulation. Tiny-Twin [17] applies time-varying, multi-tap channels on commodity CPUs, with per-UE isolation and RIC integration. ACHEM [18] virtualizes the USRP interface for UHD-based applications, including GNU Radio, srsRAN, and OAI, and supports channel impairments, mobility, and MIMO. These approaches provide full-stack channel emulation through different computation and radio-interface designs. The Sionna Research Kit provides a particularly close GPU-based reference: its CUDA plugin applies CIRs within the OAI gNB in USRP and RF-simulator configurations [22]. The cited implementation supports SISO and accepts file-based or streamed CIRs. M IRAGE combines batched multi-link SISO/MIMO filtering with timestamped sharedmemory transport and per-interval selection of complete channel-response versions. We evaluate this combination through waveform and update-consistency tests, bidirectional timing measurements, and full-stack delivery experiments, including concurrent instances.

4

2.4

Channel Fidelity and Live Coupling

Channel-model accuracy and emulator correctness require distinct validation. Hofer et al. [7] compare simulated and emulated time-varying channel responses, while Villa et al. [6] validate Colosseum scenarios against physical experiments. Rauf et al. [26] examine system-level KPI deviations between Sionna RT and measured channels in an OAI hardware-in-the-loop testbed. These studies inform the separation of waveform validation from physical-network agreement in our evaluation. Pegurri et al. [27] integrate Sionna RT with the eventdriven ns-3 simulator, and AIRMap [28] estimates sitespecific radio maps. The former evaluates channel effects through network-layer and application-layer simulation, while the latter supplies propagation estimates; neither provides the continuous IQ-processing path considered here. TwiNet [29] addresses live coupling through bidirectional MQTT exchange between physical networks and digital replicas. Our testbed study connects IQ-level emulation to such a state-and-control loop and examines how prediction errors affect physical reconfiguration.

3

S YSTEM A RCHITECTURE

Figure 1 shows the integration of M IRAGE into a full-stack wireless DT. Each twin runs a software gNB, software UEs, and a 5G core, with M IRAGE applying per-link channel responses to the IQ samples exchanged between the radio stacks. The architecture separates continuous IQ processing from asynchronous channel generation and network control. 3.1

Overview

Each instance contains an OAI or OCUDU gNB, OAI software UEs, an Open5GS core, and the M IRAGE channel emulator. Stack-specific radio drivers adapt the gNB interface to a common IQ transport; channel processing is independent of the selected gNB stack. The monitoring and control integration and physical-network case study described here use OAI. Three paths connect these components to the channel-model server and the control system. The IQ path carries timestamped baseband samples between the gNB, emulator, and UEs through shared memory. The channel-update path supplies externally generated per-link responses to the emulator through Redis. The monitoring and control path carries gNB measurements and resourceallocation requests through the E2 interface, with the broker coordinating information exchange and experiment execution. Only the IQ path follows the radio stack’s sampleprocessing deadlines. Section 4 describes its transport and GPU processing mechanisms. The physical deployment used for validation is the X5G testbed at Northeastern University [30], with an OAI gNB, commercial Foxconn Radio Units (RUs), and commercial handsets. The twin uses corresponding gNB radio settings and replaces the handsets with OAI software UEs. The physical network and the twin use matching radio settings, but their receivers can behave differently. Section 6.1 specifies the experimental configuration. Independent instances support concurrent experiments with different candidate configurations. Their execution

rate depends on the available CPU and GPU resources. Section 5.7 evaluates both traffic delivery and radio-clock progression under concurrent operation; Section 6 evaluates an iterative slice-control procedure using one twin and the physical deployment. 3.2

Broker

The broker is a Python service that provisions containerized DT instances and coordinates configuration exchange, measurement access, and candidate-policy evaluation. Redis provides storage and messaging for these exchanges. The broker uses scene descriptors, UE locations, and radio settings to configure new instances. Each instance starts its own protocol processes; live HARQ state and packet buffers are not transferred from the physical network. In the physical-network case study, the environmental inputs are an imported CAD scene and transmitter and receiver locations measured against the floor plan. Radio settings are matched through experiment configuration. During operation, the monitoring xApp writes perUE throughput measurements to Redis, and the channelmodel server publishes CFR updates. This experiment uses a configured scene rather than continuous sensing of the physical environment. The control logic uses the measurements to assess candidate PRB quotas in the twin. The broker coordinates delivery of selected settings to the control xApp, which issues the corresponding request to the target gNB through E2. Thus, the broker manages experiment execution and information exchange, while the xApps provide the monitoring and control interfaces. The physical deployment and the twin exchange configuration and measurements without IQ-sample alignment. The broker remains outside the slot-rate IQ path, and each instance maintains its own radio timing. Channel updates and control exchanges proceed asynchronously. 3.3

Channel Generation and Delivery

An external channel-model server supplies per-link CFRs. Our reference deployment uses Sionna RT [31] to compute site-specific propagation from scene geometry, material properties, and transmitter and receiver locations. The emulator accepts scalar responses for SISO links and matrixvalued responses for MIMO links. The server publishes responses through Redis to the emulator’s channel subscriber. At the start of each processing interval, each direction selects the latest accepted response for each link and retains that version throughout the interval. Channel generation determines how frequently propagation coefficients are refreshed, while the IQ path continues processing with the available coefficients. Section 4.7 describes version consistency and the frequencygrid, antenna-layout, and data-format requirements for alternative modeling backends. Receiver noise is configured separately from the propagation response, as described in Section 4.2. 3.4

Near-RT RIC and Control xApps

We use the OSC Near-RT RAN Intelligent Controller (RIC) [32] with monitoring and control xApps built using

5

xDevSM [33].1 The monitoring xApp collects per-UE measurements through the E2 Key Performance Measurement (KPM) service model [34] and stores them in Redis for policy evaluation and comparison between the physical and virtual domains. The control xApp uses the slice-level PRB-quota action of the E2 RAN Control (RC) service model [35] to configure resource allocation on the target gNB. Candidate quotas are evaluated on the DT-side gNB before selected values are applied to the physical gNB. Subsequent monitoring assesses the physical response and supports further evaluation when a selected quota does not meet the policy objective. Section 6.2 details the procedure and Section 6.4 reports its outcomes.

4

CUDA-BASED C HANNEL E MULATION

M IRAGE applies per-link channel responses to timestamped IQ streams through GPU filtering, shared-memory transport, and asynchronous coefficient updates. We describe the single-gNB path used in the evaluation. The implementation sets configuration limits of 64 UEs and four transmit and receive antennas per link; Section 5 reports the evaluated configurations and their timing limits. 4.1

Frequency-Domain Signal Processing

The radio interface exchanges complex samples with signed 16-bit real and imaginary components (c16). The emulator applies frequency-domain filtering using overlap-save with transform size C and a configured maximum impulseresponse length Lmax . The current implementation uses C = 4096. Each transform contains Lmax − 1 preceding input samples and P = C − Lmax + 1 new samples. Let N denote the number of samples per antenna in a processing interval; N = Nslot when the interval is one radio slot. The transform batch contains M = ⌈N/P ⌉ blocks. A GPU kernel converts the input to complex single precision and zeropads any unused positions in the final block. After channel multiplication and inverse transformation, the output kernel discards the first Lmax − 1 samples of each block and retains exactly N output samples. It also applies the 1/C inversetransform normalization and saturation to the c16 range. Initialization requires Lmax ≤ C/2, with a default of Lmax = 512. The transform count M therefore depends on the interval length and configured filter support. The processing interval has duration τint = N/fs , where fs is the sampling rate in samples per second. The emulator processes the complete time-domain waveform, including cyclic prefixes, without decoding OFDM symbols. Its transform bins are therefore processing bins, not necessarily the radio’s OFDM subcarriers. For block m ∈ {0, . . . , M − 1} and FFT bin q ∈ {0, . . . , C − 1}, let Xm [q] and Ym [q] denote the complex input and filtered output spectra, respectively, and let H[q] denote the scalar channel frequency response. The channel operation is

Ym [q] = H[q]Xm [q],

0 ≤ q < C.

1. https://github.com/wineslab/xDevSM

(1)

With a fixed transform size, the FFT work per interval scales as O(M C log C) and the scalar multiplication as O(M C) per link. Direct filtering with an L-tap impulse response instead requires O(N L) operations per link. Section 5.3 compares processing latency with a matched CPU baseline and quantifies the benefit of batched GPU dispatch. For a fixed channel with at most Lmax causal taps, overlap-save produces the same output as direct timedomain convolution, up to floating-point and quantization errors. The emulator maintains input history separately for each input stream across processing intervals. Forward timestamp gaps are represented by zero input; backward or repeated timestamps reset the history. When transmission on a link stops, zero input is processed with the retained input history to emit the remaining channel tail. The responsesupport check and coefficient-update policy are described in Section 4.7; Section 5.4 evaluates signal fidelity for the tested configurations. 4.2

Multi-UE and Multi-Antenna Processing

On the downlink, all UEs receive a channel-filtered version of the gNB waveform. The emulator computes the forward transform once per transmit antenna and retains the result in an immutable device buffer. Each UE’s channel application reads this common spectrum and writes to a separate output region. We index the K UEs by k ∈ {1, . . . , K}. Bold symbols denote vectors or matrices. For UE k , DL Yk,m [q] = Hk [q]XDL m [q],

(2)

ntx is the gNB transmit spectrum, where XDL m [q] ∈ C DL nrx is the filtered spectrum at UE k , and Yk,m [q] ∈ C Hk [q] ∈ Cnrx ×ntx is its channel matrix. Here, ntx and nrx refer to the downlink antenna roles. SISO reduces these quantities to scalars. The equations describe channel filtering before receiver noise, output gain, and quantization. A GPU kernel applies the channel matrices across UEs and bins, and batched inverse transforms recover one waveform per UE receive antenna. Sharing the input spectra avoids repeating the forward transforms for each UE. On the uplink, the emulator transforms each participating UE’s transmitted waveform and sums the channelweighted contributions in the frequency domain. For each coefficient version, the MIMO implementation represents uplink reciprocity through the transpose of the downlink matrix: K X UL UL Ym [q] = HT (3) k [q]Xk,m [q]. k=1 nrx UL Here, XUL is the UE transmit spectrum, Ym [q] ∈ k,m [q] ∈ C ntx T C is the combined spectrum at the gNB, and (·) denotes transpose. Antenna roles reverse on the uplink. The sum is inverse-transformed once per gNB receive antenna, producing a composite waveform of simultaneous UE transmissions. The current MIMO interface requires equal configured transmit and receive antenna counts. Each equation uses the coefficient version selected for that direction and processing interval; the version index is omitted for brevity. The two directions select versions independently, as described in Section 4.7.

6

Channel producer → Redis subscriber → Versioned CFRs

Radio stack write

Common IQ rings

GPU channel emulator

Per-UE IQ rings

Downlink gNB transmit samples

Downlink: shared FFT, per-UE filtering Apply channel Hk [q] → IFFT → IQ

read Downlink k UE receive samples

Uplink: per-UE FFT, channel and sum Combine UE signals → IFFT → IQ

write Uplink k UE transmit samples

gNB process read

Uplink gNB receive samples

Radio stacks

UE k process k = 1, . . . , K

Fig. 2. IQ transport and GPU processing for one gNB and K UEs. Downlink processing applies per-UE channels to a common gNB waveform; uplink processing combines channel-filtered UE waveforms. Shared-memory rings carry time-domain IQ samples, while CFR updates arrive asynchronously.

Receiver noise and output gain are configured separately from the propagation coefficients. Noise power follows thermal noise and a configured receiver noise figure, unless explicitly specified. Physical-network agreement requires separate calibration. The downlink output kernel normalizes the inverse transform, adds Additive White Gaussian Noise (AGWN), applies the per-UE gain in floating point, and quantizes the result. Uplink noise is added after combining UE contributions, representing noise at the gNB receiver. 4.3

Timestamped Shared-Memory Transport

Stack-specific gpuemu radio drivers connect the radio stacks to a common shared-memory interface. The OAI driver uses the openair0 read and write callbacks; the OCUDU plugin implements its radio-session interface (Section 4.5). The gNB writes its downlink samples to a common POSIX shared memory (SHM) segment, and the emulator writes each filtered waveform to a per-UE downlink segment. In the reverse direction, each UE writes to its own uplink segment, and the emulator publishes the composite waveform to the gNB’s uplink segment. This requires 2(K + 1) IQ segments for one gNB and K UEs (Fig. 2). Antenna streams occupy separate planes within each segment. Each antenna plane stores B = 8,601,600 complex samples, providing B/fs seconds of buffering at sampling rate fs . Sample n is stored at ring-buffer offset n mod B . The producer writes all antenna samples before advancing the publication timestamp. Readers validate requested intervals against this timestamp and the ring capacity. An atomic sequence counter and Linux futex wakeups provide interprocess notification. The emulator registers shared-memory sample planes with CUDA for asynchronous host–device transfers, removing an intermediate host copy. Valid, contiguous ranges use direct transfers; wraparound, incomplete input, or unavailable registration selects a pinned staging buffer. Output is published only after the device-to-host transfer completes, preventing readers from accessing unfinished GPU output. 4.4

Slot Timing and Uplink Collection

Separate host threads process downlink and uplink samples. The downlink thread waits for samples produced by the gNB. The uplink thread is paced by the host’s

monotonic clock, with successive deadlines separated by the processing-interval duration τint . It also checks the downlink processing timestamp and waits if its own timestamp is more than one interval ahead. By default, this wait continues until downlink processing catches up, so a downlink stall can also stop uplink progress. An optional timeout allows uplink processing to continue despite that stall. These rules set the intended processing pace; meeting the deadlines still depends on host scheduling and processing time. For each uplink interval, one worker per UE waits for that UE’s samples. The workers run concurrently and account for the offset between UE transmit timestamps and the gNB receive window, including timing advance. These sample-collection waits are separate from the downlinkprogress wait described above. If a collection wait expires, the collector can use the samples already available at the start of the interval and fill the missing portion with zeros. A link with no available samples contributes zero input, although its retained filter history may still produce a channel tail. Concurrent collection avoids adding a separate wait for every UE; completion depends on the last worker to finish and the configured timeouts. During GPU initialization, a temporary thread advances the gNB-facing uplink publication timestamp, which identifies how far samples have been made available to the gNB. The emulator then selects a starting timestamp from the gNB downlink position and advances lagging ring timestamps to that reference. This establishes the initial samplecounter positions but can leave an offset between those counters and the actual sample content. If downlink processing falls behind and resumes at a newer timestamp, the emulator first clears the skipped ranges in the UE output rings, then advances their publication timestamps. Readers therefore receive zeros for those ranges rather than stale samples from an earlier traversal of the ring. 4.5

OCUDU Integration

M IRAGE also supports an OCUDU gNB communicating with OAI software UEs. A radio driver connects OCUDU to the same timestamped IQ interface used by OAI, while preserving the timing required by its physical layer. The integration reuses the channel emulator without modification

7

and requires only build and configuration adaptations for the OAI UEs. This separation allows different gNB stacks to use the same channel-processing framework. 4.6

GPU Execution and Resource Management

Per-antenna FFT plans, device workspaces, and pinned staging buffers are allocated during initialization. The multi-UE inverse-transform plan is created on first use and recreated when the UE count changes. Preallocation avoids repeated workspace allocation during steady-state processing, while ping-pong buffers separate successive submissions. Downlink processing batches channel application and inverse transforms across UEs. Uplink processing orders input transforms, matrix mixing, and output transforms through CUDA streams and synchronization. The host waits for output completion before publishing samples. CUDA’s blocking synchronization policy allows waiting host threads to yield the CPU. 4.7

Asynchronous Channel Updates

The channel producer sends per-link CFRs through Redis independently of IQ processing. Each update identifies the link, version, antenna dimensions, and frequency grid and contains complex single-precision coefficients. The producer and emulator must use matching carrier frequencies, sample rates, and antenna layouts. The subscriber validates each update and converts its frequency-bin ordering when needed. Before uploading a response, the emulator rejects nonfinite coefficients and checks the impulse-response energy beyond Lmax samples. If that energy fraction exceeds the configured tolerance (default 10−3 ), the update is rejected. Otherwise, tails above numerical precision are removed and the CFR is reconstructed. Disabling this check removes the linear-convolution guarantee for longer responses. These checks run outside the IQ-processing loop. Each link uses four GPU coefficient buffers. A new version becomes available only after its upload completes. IQ processing continues with the current coefficients during this upload; it does not wait for the next channel response. At the start of each interval, each direction selects the latest available version for each link and uses it throughout that interval. A buffer is reused only after both directions finish using it, preventing partially updated coefficients from entering the filtering operation. Downlink, uplink, and different links select versions independently, so updates are not simultaneous across the network. Intermediate versions may be replaced before use, and coefficients are not interpolated. This mechanism ensures complete updates; their freshness depends on the producer and delivery delay.

5

E VALUATION

We evaluate M IRAGE on an H100 platform through component tests of processing time, waveform accuracy, and channel-update consistency, followed by full-stack delivery and concurrent-instance experiments. We check whether processing finishes within each slot, whether traffic is delivered, and whether the radio clock keeps pace with wall time.

5.1

Platform and Measurement Methodology

Experiments use one NVIDIA H100 SXM GPU with 80 GB of memory on a dual-socket Intel Xeon Platinum 8468 host and the OAI 2026 week 38 release. Component tests use synthetic radio peers; full-stack tests execute OAI gNB and UE stacks unless explicitly identified as OCUDU SISO tests in Section 5.8. In single-gNB tests, K denotes the number of gNB–UE links. We focus on FR1, using 30 kHz SCS for full-stack tests and 15 and 30 kHz for component comparisons, consistent with OAI support [36]. We omit 60 kHz because our timing test uses equal-sized blocks, whereas OAI alternates slot sample counts at this SCS. The 120 kHz setting is outside our FR1 scope. Each component timing configuration uses five independent process starts, a 30 s warm-up, and a 60 s measurement window, with channel updates at 10 Hz. Tests run in isolation with real-time scheduling for processing threads. GPU assignment, thread priorities, and CPU affinity are verified before full-stack traffic and after cell restarts. The waveform tests include two operations that prevent old or missing samples from reaching the receiver: clearing skipped intervals in the sample buffer and returning zeros when a driver read fails. Processing time is measured without these two operations. Their added processing time has not been measured. 5.2

Processing Time and Scaling

Figure 3 reports the mean of the five per-run 99th-percentile processing times, with 95% Student-t confidence intervals across starts. Processing time covers input collection, GPU work, and output publication within each interval; it does not measure the full delay from input availability to output publication. Buffering and startup alignment can add delay. Downlink statistics include all measured slots, whereas uplink statistics include slots with a UE write. The time available to process N samples at sampling rate fs is τint = N/fs . When one interval covers one NR slot, its nominal duration is 1/2µ ms, where the subcarrier spacing is 15 × 2µ kHz [8]. Figure 3 marks the nominal budgets for 15 and 30 kHz SCS. The plotted measurements use 30 kHz SCS, so their processing budget is 500 µs. For comparisons across SCS values, Fig. 4 reports p99 processing time divided by the interval duration; a value of one means the full budget is used. A configuration meets the processing criterion only when both directions have p99 at most τint and fewer than 1% of intervals exceed that budget in every start. Uplink processing limits the tested operating range (Table 2). At 61.44 Msps with four 2 × 2 links, mean perrun p99 is approximately 255 µs downlink and 383 µs uplink. At 122.88 Msps with the same link and antenna counts, it increases to 368 µs and 535 µs, respectively; the mean fraction of active uplink intervals above budget is 19.9%. Thus, a downlink-only timing assessment would overstate the bidirectional operating range. The eight-link, 122.88 Msps 2 × 2 case reaches 836 µs uplink p99. All tested configurations meet the harness delivery criterion, including those that exceed the processing budget. The longer receive wait and TDD traffic pattern allow delivery despite active uplink intervals exceeding one slot.

Per-run p99 (µs)

61.44 Msps, SISO 61.44 Msps, 2 × 2 61.44 Msps, 4 × 4

122.88 Msps, SISO 122.88 Msps, 2 × 2

1 000

15 kHz: 1000 µs

750

30 kHz: 500 µs

500

p99 processing / slot duration

8

DL

0.5

0

15/1

4

8

30/1

30/4

Fig. 4. Processing time relative to the slot budget at 15 and 30 kHz SCS. Points show mean per-run p99 ratios with 95% confidence intervals.

0 2

15/4

SCS (kHz) / links

250

1

UL

1

16

Number of links, K 30,720 samples

1 000

15 kHz: 1000 µs

750

30 kHz: 500 µs

500 250

CPU/GPU latency ratio

Per-run p99 (µs)

(a) Downlink

3 2 1 0 1

2

4

8

8

16

Number of links, K

0 1

61,440 samples

16

(a) GPU versus six-core FFTW baseline

(b) Uplink Fig. 3. Processing time versus link count at 30 kHz SCS. Error bars show 95% confidence intervals. Horizontal lines mark the labeled slot budgets. TABLE 2 Highest passing link count among tested configurations.

Rate (Msps) 61.44 61.44 61.44 122.88 122.88

Antennas

Highest passing K

SISO 2×2 4×4 SISO 2×2

8 4 1 8 1

At 61.44 Msps with 2 × 2 links, Fig. 4 compares 1 ms and 0.5 ms intervals over five starts, with approximately matched TDD time allocation. The shorter interval reduces the batch size but increases the fraction of the budget used by uplink processing at four links. This comparison uses synthetic peers rather than full-stack operation. 5.3

Per-link / batched time

Number of links, K

2.5 2 1.5 1 1

8

16

Number of links, K (b) Batched versus per-link GPU dispatch Fig. 5. Matched computational comparisons for 64-tap SISO filtering. Values above one favor batched GPU processing. Points show geometric means of five paired median-latency ratios; whiskers show 95% confidence intervals.

interval: 2.90–2.95). GPU acceleration therefore increases with workload size in these tests. Batching reduces dispatch overhead as the number of links increases. At 16 SISO links, the per-link-to-batched time ratio is 2.73× for 30,720 samples and 2.51× for 61,440 samples. At the latter size, the CPU-to-GPU ratio varies only from 2.55× to 2.57× across the tested 16–128-tap channels. This limited variation applies to the tested filter lengths and fixed workload.

Matched Computational Baseline

Figure 5 compares GPU filtering with a matched six-core FFTW CPU baseline for 64-tap SISO channels. For each of five paired runs, we divide the median CPU time by the median GPU time. We report the geometric mean of these ratios and its 95% confidence interval. At one link, the CPU is faster for 30,720 samples and approximately equal for 61,440 samples. At 16 links, GPU acceleration reaches approximately 1.95× and 2.55×, respectively. A separate eight-link 2 × 2 case at 61,440 samples reaches 2.93× (95%

5.4

Waveform Accuracy and Channel Updates

We check waveform accuracy by comparing the emulator output with the expected samples for known channel responses. Tests cover SISO and 2 × 2 links at 61.44 and 122.88 Msps, in both directions, with one link and five random seeds per configuration. Across 160 tests, identity and delayed-impulse channels match exactly. Dense longsupport and near-saturation channels differ by at most one integer quantization step per real or imaginary component.

Coefficient first-use p99 (ms)

9

10 updates/s

TABLE 3 Receiver goodput (Mbps): mean and 95% confidence interval.

100 updates/s

4 3 2 1 0 2×2

SISO

Antenna configuration

K

Dir.

Offer

Goodput

1 1 2 2 4 4 8 8

DL UL DL UL DL UL DL UL

20 32 80 64 160 64 320 32

19.87 ± 0.06 31.91 ± 0.23 79.85 ± 0.36 63.98 ± 0.01 159.89 ± 0.05 63.98 ± 0.01 319.47 ± 1.01 32.00 ± 0.00

Fig. 6. Delay before new channel coefficients are first used. Points show each run’s largest stream-level p99.

We also check that each processing interval uses a complete channel response, without mixing old and new coefficients. SISO and 2 × 2 tests use 10 and 100 updates/s, five runs per configuration, and a 5 ms uplink receive wait. No mixed updates are detected across 16.7 million analyzed slots, and every received update is applied. Figure 6 reports the first-use delay for supplied channel coefficients. The tests use synthetic coefficient updates and do not measure channel-model computation, such as ray tracing. For each run, we plot the largest p99 delay among the gNB uplink and the two UE downlink streams. Values range from 1.90 to 2.63 ms for SISO and from 3.51 to 4.16 ms for 2 × 2. The ranges at 10 and 100 updates/s overlap in both antenna configurations. IQ processing continues with the current coefficients while the next response is received and uploaded. The emulator selects a complete response at the start of a processing interval, as described in Section 4.7. Thus, the update delay does not represent a pause in IQ processing. These tests do not measure the processing overhead of asynchronous updates. 5.5

Full-Stack Traffic Delivery

We emphasize 2 × 2 operation because it matches the antenna configuration used in our X5G laboratory deployment (Section 6.1). Full-stack tests use a 100 MHz carrier, 273 resource blocks, 30 kHz subcarrier spacing, and 2×2 antennas. Each configuration uses five independent cell starts, a 60 s warm-up, and sequential 120 s downlink, uplink, and bidirectional tests. Per-slot instrumentation is disabled, and the gNB uplink receive wait is 5 ms. Receiver-side iperf3 UDP reports provide goodput and packet loss. Results exclude repeated tests after a restart. Table 3 shows that mean goodput closely tracks the offered load for runs with all receiver records available. Each configuration is tested over five independent cell starts; averages and Student-t confidence intervals use the available complete receiver records. At four UEs, all five runs provide receiver records in each direction, delivering 159.89 Mbps downlink and 63.98 Mbps uplink under offers of 160 and 64 Mbps. At eight UEs, mean downlink goodput is 319.47 Mbps under a 320 Mbps offer, based on two runs. These measurements demonstrate traffic delivery at the tested loads; they do not establish maximum throughput. We also evaluate simultaneous downlink and uplink traffic with four UEs. Across five runs with all receiver

records available, mean goodput is 79.71 Mbps downlink and 31.88 Mbps uplink under aggregate offers of 80 and 32 Mbps, respectively. These results complement the separate-direction measurements in Table 3. To assess operation across cell starts, we require all flow records, at least 95% of the offered rate per flow, aggregate packet loss no greater than 1%, and no detected synchronization or connectivity failure. At four UEs, all five starts meet these criteria in each separate direction, and three meet them under bidirectional traffic. At eight UEs, the corresponding counts are two, four, and two. Synchronization failures also occur when channel filtering is bypassed, so the tests do not identify their cause. Goodput from the available receiver records therefore does not establish reliable operation across all starts.

5.6

Channel Fidelity from SRS Measurements

We compare the applied uplink channel with channel estimates obtained from sounding reference signals (SRS) at the OAI gNB. Tests use one UE, 106 resource blocks, 30 kHz SCS, and 61.44 Msps sampling. Identity, delayed singlepath, and two-path SISO channels and a 2 × 2 two-path channel each use five independent starts. SRS observations are collected every 80 ms at six uplink noise levels and with noise disabled. SNR is calibrated from occupied and empty SRS comb resource elements. Before comparing the responses, we remove one common complex gain and delay per observation, fitted jointly across all sounded subcarriers and, for 2 × 2, all four channel entries. The comparison therefore evaluates channel shape rather than absolute gain, phase, or propagation delay. Figure 7 compares the applied response with a representative SRS observation for each channel. The 2×2 entries are indexed by receive antenna and UE port; their references average each subcarrier pair sharing one estimate. The estimated peaks and notches follow the applied responses across the sounded band. The channel-estimation error follows the expected inverse-SNR trend within 0.13 dB for SISO and within 0.1 dB for 2 × 2 up to 16 dB SNR. Measured noise power is 1.00 ± 0.01 times the configured value, and receiver gain varies by no more than 0.02 dB. With injected noise disabled, the error floors are approximately −43 dB for SISO and −33 dB for 2 × 2. These residual errors limit the agreement at high SNR; their causes are not fully established.

10 S-2P estimate

M-2P (0,0) applied

M-2P (0,0) estimate

M-2P (1,0) applied

M-2P (1,0) estimate

DL

p99 / slot budget

S-2P applied

|H| (dB)

0 −5 −10

1

0.5

0

−15

2

1 −20

−10

0

10

Fig. 7. Applied (lines) and SRS-estimated (markers) channel magnitude without added noise: two-path SISO (S-2P) and two 2 × 2 entries (M2P). Common receiver gain is removed.

The seven-sample channel delay is affected by the UE timing-advance loop, so these measurements do not directly validate absolute propagation delay. At the lowest SNR, some SISO runs undergo re-access; the analysis retains observations under the dominant UE identifier, reducing the available samples. Trace collection takes approximately 5 µs per SRS occasion for SISO and 17 µs for 2 × 2. Comparison with one trace-disabled start per antenna mode shows no additional attributable deadline misses. The results support agreement between the applied channel shape and the receiver estimate under the tested conditions. Concurrent Full-Stack Instances

We test J = 1, 2, 4 independent cells on one H100. Each cell uses 40 MHz bandwidth, 30 kHz SCS, 2 × 2 antennas, an identity channel, and two UEs receiving 20 Mbps each. Dedicated physical cores are assigned to the emulator, gNB, and each UE (3/4/2), with four additional cores for the core network. Each emulator uses a dedicated 1g.20gb MultiInstance GPU (MIG) partition with 26 streaming multiprocessors and 20 GB of memory. The partition size is fixed across configurations; unused partitions remain idle. After a 15 s warm-up, traffic runs for 60 s. Figure 8 shows five completed deployments per configuration. Starts with lost UEs or failed flows are repeated at most twice; five, seven, and nine starts are needed at J = 1, 2, 4, respectively. Each cell must meet the processing and delivery criteria above, advance within 1% of real time, and accumulate at most 1 ms of backlog. UL timing includes intervals with processed samples; receive timeouts are counted separately. Single-cell deployments meet all criteria in all five runs, with UL p99 of 316–338 µs and approximately 40 Mbps goodput. At J = 2, four of five completed deployments meet all criteria, delivering 79.96–79.99 Mbps. UL p99 spans 360–515 µs, with up to 1.97% of active intervals above budget; receive timeouts reach 48.8% of all intervals in one cell. Completed deployments can still contain timing or synchronization failures. At J = 4, goodput is 159.09–159.82 Mbps and DL p99 is 294–363 µs. The 19 plotted UL p99 values span 439–564 µs. Active UL intervals above budget range from 0.14% to 5.40%, and two completed deployments include resynchronization. Every completed cell maintains real-time

4

Concurrent cells

20

Baseband frequency (MHz)

5.7

UL

Fig. 8. Per-cell p99 relative to the slot budget across five completed deployments. All cells use dedicated MIG partitions; the dashed line marks the budget.

radio-clock progression, but no four-cell deployment meets all criteria. Thus, two-cell operation meets the criteria in four completed runs, while only the single-cell configuration meets them in all five. 5.8

OCUDU SISO Validation

We validate OCUDU operation with OAI software UEs in a SISO configuration using a 3.75 GHz carrier, 40 MHz bandwidth, 30 kHz SCS, and 61.44 Msps sampling. With one UE and an ideal channel, the UE completes synchronization, random access, registration, and IP connectivity. A 10 s traffic test delivers receiver throughputs of 12.05 Mbps downlink and 11.91 Mbps uplink. These measurements confirm end-to-end operation of a second gNB stack through the same M IRAGE IQ interface. 5.9

Scope and Limitations

The H100 evaluation supports the tested filtering accuracy, update consistency, and workload-dependent acceleration. It does not establish saturation capacity, rare-failure reliability, full-stack delivery latency, or long-term reliability of concurrent cells. The observed bidirectional synchronization failures limit full-stack reliability. The reported processing times apply to the tests described in Section 5.1. Our implementation copies IQ samples between host and GPU memory, including when the host buffers are registered with CUDA. Grace Hopper provides coherent CPU–GPU memory access through NVLink-C2C [37], which could allow the emulator to access CPU-resident IQ buffers without explicit copies. Whether this improves processing latency or reduces deadline misses requires measurement and depends on memory placement, access patterns, and synchronization. The separate physical-network case study is presented in Section 6.

6

D IGITAL T WIN -A SSISTED N ETWORK C ONTROL

We evaluate M IRAGE in a slice-control experiment coupled to the X5G physical RAN. The case study compares physical and twin throughput under LoS and NLoS conditions, then examines the transfer of PRB quotas selected in the twin to the physical gNB. It assesses how prediction errors affect the number of physical reconfigurations required to meet a throughput cap.

11

all PRBs. Because throughput also depends on channel and receiver behavior, a quota satisfying the cap in the twin may not satisfy it on the physical link. Candidate quotas are evaluated sequentially in one twin. Let τwarm denote the baseline warm-up duration and τmeas the measurement duration for each candidate and its physical validation, both in seconds. The procedure has four phases:

UE 1 LoS

gNB

Conference room

UE 2 NLoS

Phase 1 – Baseline monitoring. The physical deployment and the twin run with the scheduler’s default allocation for τwarm seconds. The KPM xApp records per-slice throughput Tsphy and T̂sDT in Redis. Phase 2 – Violation detection. A twin throughput measurement exceeding Tsmax triggers quota exploration for slice s through the broker.

Fig. 9. Deployment on the sixth floor of Northeastern University’s EXP building. UE 1 has a LoS path to the gNB; the conference room obstructs the direct path to UE 2 (NLoS).

6.1

Scenario and Testbed Configuration

The experiment uses the indoor X5G deployment on the sixth floor of Northeastern University’s EXP building (Fig. 9). UE 1 has a LoS path to the gNB, whereas a conference room obstructs the direct path to UE 2. Each UE belongs to a separate slice: Slice Differentiator (SD) 0 for UE 1 and SD 1 for UE 2. The physical gNB uses a Foxconn RPQN O-RU at 3.75 GHz with 40 MHz bandwidth, 30 kHz SCS, 2 × 2 antennas, and TDD pattern DDDDDDDSUU. It runs an OAI Distributed Unit (DU)/Central Unit (CU) stack with an Open5GS 5G Core (5GC); the UEs are Samsung Galaxy S23 handsets. The twin uses the corresponding OAI and Open5GS configuration, with OAI nr-uesoftmodem processes replacing the handsets and the gpuemu driver connecting the stacks to M IRAGE. Numerology, bandwidth, TDD pattern, MCS table, slice configuration, and antenna count are matched between the two domains. Receiver implementation and hardware differences remain possible sources of throughput disagreement. Sionna RT uses an imported CAD model of the floor and gNB and UE coordinates measured against the floor plan. It computes per-UE CFRs Hk [q] on the emulator’s FFT grid and publishes them through Redis at approximately 10 Hz. This quasi-static scenario uses configured geometry and positions rather than continuous environmental sensing. The monitoring and control xApps described in Section 3 collect per-UE throughput and apply slice-level PRB quotas through E2. 6.2

Network Policy and Closed-Loop Procedure

Let s ∈ {0, 1} denote the slice index, with UE k = s + 1 assigned to slice s. The policy imposes a downlink throughput cap: Ts ≤ Tsmax , s ∈ {0, 1}, (4) where Ts is measured slice throughput. The caps are T0max = 25 Mbps and T1max = 10 Mbps. The controller adjusts each slice’s maximum PRB quota ρs . These quotas bound resource use; they do not specify a fixed partition of

Phase 3 – Quota exploration. The RC xApp reduces the violating slice’s maximum quota from 100% in steps of ∆ρ = 5 percentage points, within the range [10%, 100%]. Each candidate is applied to the twin and evaluated over τmeas seconds. The search selects the first candidate meeting (4), denoted ρ⋆s . This descending search seeks a less restrictive quota, but time-varying measurements do not establish a globally optimal allocation. Phase 4 – Deployment and monitoring. The RC xApp applies ρ⋆s to the physical slice, whose throughput is recorded for τmeas seconds. Twin monitoring continues after deployment. If the twin again exceeds the cap, exploration resumes from the current quota and may produce another physical update. Thus, renewed exploration is triggered by the twin measurements; a physical violation alone does not establish that another search will occur. 6.3

Digital Twin Fidelity Assessment

Before control, each UE is offered a 50 Mbps downlink User Datagram Protocol (UDP) flow generated using iperf3, with the core-side endpoint co-located with the User Plane Function (UPF). The KPM xApp collects DRB.UEThpDl DT

from both gNBs. For slice s, let T̄sphy and T̂ s denote mean throughput over the steady-state comparison window. The signed relative error is DT

ϵs =

T̄sphy − T̂ s T̄sphy

,

s ∈ {0, 1}.

(5)

Positive values indicate underestimation by the twin; negative values indicate overestimation. Figure 10 shows the throughput traces. The mean errors are ϵ0 = −1.45% for the LoS UE and ϵ1 = 36.5% for the NLoS UE. The LoS means agree closely under the tested offered load. Since both are near 50 Mbps, this agreement does not establish equal link capacity or channel fidelity. The NLoS twin underestimates physical throughput and exhibits less variability in the displayed trace. Propagation modeling, receiver implementation, and hardware differences may contribute to this discrepancy; the experiment does not isolate their effects. The control experiment below examines the consequence of this disagreement for quota selection.

12 Digital Twin

Physical

Digital Twin

PRB quota (Physical)

PRB quota (Twin)

Threshold 60 3

2

20 0 0

10

20

30

40

Elapsed time (s)

4

60

100

40 50 20

0 0

(a) LoS

10

20

30

40

50

MAX PRB (%)

40

DL throughput (Mbps)

DL throughput (Mbps)

Physical

0 70

60

60

(a) LoS

40

3

2

4

0 0

10

20

30

40

Elapsed time (s) (b) NLoS

100 40

50 20

0

Fig. 10. Per-UE downlink throughput (DRB.UEThpDl) on the physical deployment and the digital twin under identical traffic load. SD = 0: LoS UE; SD = 1: NLoS UE.

0

10

20

30

40

50

MAX PRB (%)

20

DL throughput (Mbps)

DL throughput (Mbps)

Elapsed time (s)

0 70

60

Elapsed time (s)

(b) NLoS

6.4

Closed-Loop Control Results

For the LoS slice, the twin initially reports approximately 50 Mbps, exceeding the 25 Mbps cap. The search evaluates 16 intermediate quotas before selecting ρ⋆0 = 15%. The physical gNB receives one update, and its throughput falls below the cap at approximately 23 s (Fig. 11a). After the quota is applied, the physical and twin throughputs differ, although both satisfy the cap. Thus, the close baseline means do not imply equally close predictions under a restricted quota. For the NLoS slice, twin throughput fluctuates near the 10 Mbps cap while physical throughput is higher during much of the run (Fig. 11b). The controller successively deploys quotas of 65%, 35%, 25%, and 20%. Twin threshold crossings lead to resumed exploration and further quota reductions. Figure 12 records 15 intermediate twin candidates and three superseded physical updates, excluding the final action. Physical throughput is below the cap by the final update, but it is also below the cap during the preceding 25% interval. The trace therefore supports eventual compliance without establishing that the final 20% quota is the least restrictive physical setting. Throughput changes before and between updates also prevent attributing every change to a quota adjustment alone. In the observed control traces, both slices ultimately satisfy their throughput caps. The LoS case requires one physical reconfiguration, whereas the NLoS case requires four. This contrast illustrates how a twin can confine candidate testing to the digital environment when its predictions support the control decision, while prediction errors near the threshold can lead to repeated physical reconfiguration. The result does not establish guaranteed recovery from a physi-

Fig. 11. Slice throughput and maximum PRB quotas during closedloop control. Lines represent throughput, bars indicate PRB quotas, and horizontal lines mark the throughput caps of 25 Mbps for LoS and 10 Mbps for NLoS conditions. The closed-loop control phases are indicated at the top of the graph. Phase 1 is omitted because the graph begins with an already-occurring threshold violation. DT exploration

Superseded physical

✓

NLoS

✓

LoS 0

2

4

6

8

10

12

14

16

18

20

Number of control actions

Fig. 12. Intermediate actions before the final selected quota. DT exploration counts intermediate candidate quotas tested in the twin; superseded physical counts deployed quotas later replaced. The check mark denotes the final physical action, which is excluded from the bars.

cal violation: further exploration depends on another twinside trigger. Improved prediction accuracy could reduce such reconfigurations, but that benefit requires validation under repeated trials and additional channel conditions.

7

C ONCLUSIONS

We presented M IRAGE, a GPU-accelerated, IQ-level channel emulator connected to OAI and OCUDU 5G NR stacks through radio-driver plugins. The design combines batched SISO/MIMO frequency-domain filtering, timestamped shared-memory transport, and versioned channel

13

responses. External propagation models supply channel updates asynchronously, while IQ processing continues with a complete coefficient version for each link and direction. Component tests on an NVIDIA H100 confirm filtering accuracy and channel-update consistency under the tested conditions. At 61.44 Msps, the highest tested configurations meeting the bidirectional 0.5 ms processing criterion are eight SISO links, four 2×2 links, and one 4×4 link. Matched CPU comparisons show that GPU acceleration depends on workload size. OAI full-stack tests demonstrate traffic delivery at the evaluated loads, but synchronization failures limit reliability. OCUDU SISO tests also confirm end-to-end operation with OAI UEs using the same emulator. With dedicated MIG partitions, completed deployments maintain real-time radio-clock progression up to four cells. All criteria are met in five of five completed single-cell runs and four of five two-cell runs, but in none of the four-cell runs. The X5G case study uses the emulator to evaluate candidate slice quotas in the twin before applying selected settings to the physical gNB. Both slices ultimately meet their throughput caps in the observed traces, with one physical reconfiguration in the LoS case and four in the NLoS case. These results highlight the importance of prediction accuracy near the control threshold when applying decisions from the twin to the physical network. They motivate further work on full-stack synchronization, resource scheduling across concurrent instances, and calibration against physical measurements.

R EFERENCES [1]

[2]

[3]

[4]

[5]

[6]

[7]

T. Aghayev, M. Elkael, M. Polese, M. D. Nguyen, G. Gemmi, A. Lacava, A. Saeizadeh, R. Prasad, P. Testolina, A. Feraudo, S. Nanda, P. Johari, S. D’Oro, and T. Melodia, “GENESIS: Harnessing AI agents for autonomous 6G RAN synthesis, research, and testing,” May 2026, arXiv:2605.27360. [Online]. Available: https://arxiv.org/abs/2605.27360 X. Deng, J. Da, E. Pan, Y. Y. He, C. Ide, K. Garg, N. Lauffer, A. Park, C. Rane, K. Sampath, M. Krishnan, S. R. Kundurthy, S. M. Hendryx, Z. Wang, C. B. C. Zhang, N. Jacobson, B. Liu, and B. Kenstler, “SWE-Bench Pro: Can AI agents solve long-horizon software engineering tasks?” in Proc. 43rd International Conference on Machine Learning (ICML), ser. Proceedings of Machine Learning Research, vol. 306, 2026, pp. 23 917–23 934. [Online]. Available: https://proceedings.mlr.press/v306/deng26f.html W. Sentosa, B. Chandrasekaran, P. B. Godfrey, and H. Hassanieh, “CellReplay: Towards accurate record-andreplay for cellular networks,” in Proc. 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI). Philadelphia, PA, USA: USENIX Association, Apr. 2025, pp. 1169–1186. [Online]. Available: https: //www.usenix.org/conference/nsdi25/presentation/sentosa A. Alkhateeb, S. Jiang, and G. Charan, “Real-time digital twins: Vision and research directions for 6G and beyond,” IEEE Commun. Mag., vol. 61, no. 11, pp. 128–134, Nov. 2023, doi: 10.1109/MCOM. 001.2200866. M. Polese, L. Bonati, S. D’Oro, S. Basagni, and T. Melodia, “ColORAN: Developing machine learning-based xApps for open RAN closed-loop control on programmable experimental platforms,” IEEE Trans. Mobile Comput., vol. 22, no. 10, pp. 5787–5800, Oct. 2023, doi: 10.1109/TMC.2022.3188013. D. Villa, M. Tehrani-Moayyed, C. P. Robinson, L. Bonati, P. Johari, M. Polese, and T. Melodia, “Colosseum as a digital twin: Bridging real-world experimentation and wireless network emulation,” IEEE Trans. Mobile Comput., vol. 23, no. 10, pp. 9150–9166, Oct. 2024, doi: 10.1109/TMC.2024.3359596. M. Hofer, Z. Xu, D. Vlastaras, B. Schrenk, D. Löschenbrand, F. Tufvesson, and T. Zemen, “Real-time geometry-based wireless channel emulation,” IEEE Trans. Veh. Technol., vol. 68, no. 2, pp. 1631–1645, Feb. 2019, doi: 10.1109/TVT.2018.2888914.

[8]

3GPP, “NR; physical channels and modulation,” ETSI, TS 138 211, Oct. 2025, version 19.1.0. [Online]. Available: https://www.etsi.org/deliver/etsi TS/138200 138299/138211/19.01.00 60/ts 138211v190100p.pdf [9] M. Polese, L. Bonati, S. D’Oro, S. Basagni, and T. Melodia, “Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges,” IEEE Commun. Surveys Tuts., vol. 25, no. 2, pp. 1376–1411, 2023, doi: 10.1109/COMST.2023.3239220. [10] M. Polese, L. Bonati, S. D’Oro, P. Johari, D. Villa, S. Velumani, R. Gangula, M. Tsampazi, C. P. Robinson, G. Gemmi, A. Lacava, S. Maxenti, H. Cheng, and T. Melodia, “Colosseum: The open RAN digital twin,” IEEE Open J. Commun. Soc., vol. 5, pp. 5452–5466, 2024, doi: 10.1109/OJCOMS.2024.3447472. [11] Keysight Technologies, “Channel emulators,” accessed: Oct. 11, 2026. [Online]. Available: https://www.keysight.com/us/en/ products/channel-emulators.html [12] VIAVI Solutions, “Vertex channel emulator,” accessed: Oct. 11, 2026. [Online]. Available: https://www.viavisolutions.com/ en-us/products/vertex-channel-emulator [13] B. Ryu, R. Knopp, M. Elkadi, D. Kim, and A. Le, “5G-EMANE: Scalable open-source real-time 5G new radio network emulator with EMANE,” in Proc. IEEE Military Communications Conference (MILCOM), Rockville, MD, USA, Nov. 2022, pp. 553–558, doi: 10. 1109/MILCOM55135.2022.10017907. [14] U. Pawar, A. E. Ferguson, Y. Takano, J. Larrea, X. Foukas, M. K. Marina, and B. Radunovic, “Towards scalable and cost-effective RAN emulation leveraging the public cloud,” in Proc. 26th International Workshop on Mobile Computing Systems and Applications (HotMobile). La Quinta, CA, USA: ACM, Feb. 2025, pp. 43–48, doi: 10.1145/3708468.3711895. [15] OpenAirInterface Software Alliance, “OpenAirInterface RF simulator (rfsimulator),” accessed: Oct. 11, 2026. [Online]. Available: https://github.com/OPENAIRINTERFACE/openairinterface5g/ blob/develop/radio/rfsimulator/README.md [16] T. Iye, M. Sakamoto, S. Takaya, E. Sato, Y. Susukida, Y. Nagaoka, K. Maruta, and J. Nakazato, “Open wireless digital twin: Endto-end 5G mobility emulation with OpenAirInterface and ray tracing,” IEEE Access, vol. 13, pp. 175 109–175 122, 2025, doi: 10.1109/ACCESS.2025.3619105. [17] A. Mamaghani, U. Ghosh, S. Shakkottai, D. Bharadia, and I. K. Jain, “Tiny-Twin: A CPU-native full-stack digital twin for NextG cellular networks,” in Proc. IEEE Int. Symp. Spectrum Innovation (DySPAN), May 2026, pp. 1–8, doi: 10.1109/dyspan69846.2026. 11571109. [18] A. Gurses and M. L. Sichitiu, “ACHEM: A real-time digital twin framework with channel and radio emulation,” Apr. 2026, arXiv:2604.04742. [Online]. Available: https://arxiv.org/abs/2604. 04742 [19] X. Xie, W. Hou, Z. Guo, and M. Liu, “Building massive MIMO baseband processing on a single-node supercomputer,” in Proc. 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI). Philadelphia, PA, USA: USENIX Association, Apr. 2025, pp. 1221–1242. [Online]. Available: https://www.usenix.org/conference/nsdi25/presentation/xie [20] NVIDIA, “Aerial Omniverse Digital Twin documentation,” accessed: Oct. 11, 2026. [Online]. Available: https://docs.nvidia. com/aerial/aodt/welcome [21] OpenAirInterface Software Alliance, “OpenAirInterface VRTSIM: Shared-memory radio interface,” accessed: Oct. 11, 2026. [Online]. Available: https://github.com/OPENAIRINTERFACE/ openairinterface5g/blob/develop/radio/vrtsim/README.md [22] NVIDIA, “Real-time channel emulator,” Sionna Research Kit documentation, Sionna 2.1.0, accessed: Oct. 11, 2026. [Online]. Available: https://nvlabs.github.io/sionna/v2.1.0/rk/tutorials/ channel emulation/channel emulation.html [23] J. Xie, Z. Jiang, J. Liu, J. Yu, S. Luo, C. Guo, Z.-C. Hao, and W. Hong, “Design and verification of a massive MIMO channel emulator for 5G/6G system performance testing,” IEEE J. Microw., vol. 5, no. 3, pp. 640–653, May 2025, doi: 10.1109/JMW.2025. 3557566. [24] Small Cell Forum, “5G FAPI: PHY API specification,” Small Cell Forum, SCF 222, Jul. 2025, 10th ed. [Online]. Available: https:// www.smallcellforum.org/docs/5g-fapi-phy-api-specification-2/ [25] srsRAN Project, “srsRAN 4G with ZMQ virtual radios,” accessed: Oct. 11, 2026. [Online]. Available: https://docs.srsran.com/ projects/4g/en/next/app notes/source/zeromq/source/

14

[26] F. Rauf, S. Sanyal, M. Heinrichs, and A. Sezgin, “Quantifying system level KPI deviations of Sionna RT: Material and near-field error analysis using a 5G OAI testbed,” May 2026, arXiv:2605.10352. [Online]. Available: https://arxiv.org/abs/2605. 10352 [27] R. Pegurri, F. Linsalata, E. Moro, J. Hoydis, and U. Spagnolini, “Toward digital network twins: Integrating Sionna RT in ns-3 for 6G multi-RAT networks simulations,” in Proc. IEEE INFOCOM Workshops (INFOCOM WKSHPS). London, United Kingdom: IEEE, May 2025, pp. 1–6, doi: 10.1109/INFOCOMWKSHPS65812. 2025.11152946. [28] A. Saeizadeh, M. Tehrani-Moayyed, D. Villa, J. G. Beattie, P. Johari, S. Basagni, and T. Melodia, “AIRMap: AI-generated radio maps for wireless digital twins,” IEEE Trans. Wireless Commun., vol. 25, pp. 18 871–18 884, 2026, doi: 10.1109/twc.2026.3704457. [29] C. P. Robinson, A. Lacava, P. Johari, F. Cuomo, and T. Melodia, “TwiNet: Connecting real world networks to their digital twins through a live bidirectional link,” in Proc. IEEE Global Commun. Conf. (GLOBECOM), Dec. 2024, pp. 5277–5282, doi: 10.1109/globecom52923.2024.10901203. [30] D. Villa, I. Khan, F. Kaltenberger, N. Hedberg, R. S. da Silva, S. Maxenti, L. Bonati, A. Kelkar, C. Dick, E. Baena, J. M. Jornet, T. Melodia, M. Polese, and D. Koutsonikolas, “X5G: An open, programmable, multi-vendor, end-to-end, private 5G ORAN testbed with NVIDIA ARC and OpenAirInterface,” IEEE Trans. Mobile Comput., vol. 24, no. 11, pp. 11 305–11 322, Nov. 2025, doi: 10.1109/TMC.2025.3580764. [31] J. Hoydis, F. Aı̈t Aoudia, S. Cammerer, M. Nimier-David, N. Binder, G. Marcus, and A. Keller, “Sionna RT: Differen-

tiable ray tracing for radio propagation modeling,” in Proc. IEEE Globecom Workshops (GC Wkshps), Dec. 2023, pp. 317–321, doi: 10.1109/GCWkshps58843.2023.10465179. [32] O-RAN Software Community, “Near realtime RAN intelligent controller (RIC),” accessed: Oct. 11, 2026. [Online]. Available: https://docs.o-ran-sc.org/en/latest/projects. html#near-realtime-ran-intelligent-controller-ric [33] A. Feraudo, S. Maxenti, A. Lacava, L. Bonati, P. Bellavista, M. Polese, and T. Melodia, “xDevSM: An open-source framework for portable, AI-ready xApps across heterogeneous O-RAN deployments,” IEEE Trans. Netw. Service Manag., vol. 23, pp. 7636– 7649, 2026, doi: 10.1109/tnsm.2026.3733344. [34] O-RAN Working Group 3, “O-RAN E2 service model (E2SM), KPM,” O-RAN Alliance, Technical Specification O-RAN.WG3.E2SM-KPM-v02.03, 2022. [Online]. Available: https://specifications.o-ran.org/specifications [35] ——, “O-RAN E2 service model (E2SM), RAN control,” O-RAN Alliance, Technical Specification O-RAN.WG3.E2SM-RCv01.03, 2022. [Online]. Available: https://specifications.o-ran. org/specifications [36] OpenAirInterface Software Alliance, “OAI RAN: Supported features and capabilities,” accessed: Oct. 11, 2026. [Online]. Available: https://openairinterface.org/ran/ [37] J. Evans, M. Andersch, V. Sethi, G. Brito, and V. Mehta, “NVIDIA Grace Hopper Superchip architecture in-depth,” NVIDIA Technical Blog, Nov. 2022, accessed: Oct. 11, 2026. [Online]. Available: https://developer.nvidia.com/blog/ nvidia-grace-hopper-superchip-architecture-in-depth/

Related documents

• MIRAGE: A GPU-Accelerated IQ-Level Channel Emulator for Real-Time Wireless Digital Twins#1489988
• A Survey on Digital Twins: Architecture, Enabling Technologies, Security and Privacy, and Future Prospects#1135285
• Building real-time digital twin instances with Function+Data Flow: user evaluation and extension for iterative pipelines#467194
• Integration of digital twin technologies in smart grid substations#437851
• A Cloud-Native Platform for GPU-Accelerated Digital Twin Workflows in Automation Research#1210430