Remove VCD signal dumper from NR code
We don't test VCD in 5G NR code (and haven't tested it in 4G for years).
Remove the VCD traces in 5G code to avoid any ambiguity. 4G code remains
in place, as well as the tools to analyze existing traces.
Integrate GPU-Accelerated Channel Simulation + CI Test Pipeline
This MR builds on top of MR !3588 (feat: GPU Accelerated Channel
Simulation Pipeline).
The main portion of the changes is directly taken from MR !3588, and
focuses on integrating the GPU-accelerated channel simulation. On top of
that, this MR adds CI-related configurations to introduce a new channel
simulation testing pipeline into the CI --> RAN-Channel-Simulation
This MR introduces a CUDA-based pipeline to offload the
multipath_channel and add_noise channel simulation functions to the GPU.
This enables large-scale, real-time physical layer simulations not
possible on the CPU.
For full documentation, please see the file at openair1/SIMULATION/TOOLS/DOC/gpu_acceleration.md.
System & Compiler Requirements: An NVIDIA GPU with a compatible driver
and the CUDA Toolkit installed.
This feature was developed and tested on the GH200 server using the GCC
12 toolchain. To ensure reproducibility, building with GCC 12 is highly
recommended. Build Instructions
The primary flag to enable this feature is -DCUDA_ENABLE=ON. The
following command shows a sample configuration used during development
on the GH200 server:
./build_oai --phy_simulators --cmake-opt "\
-DCUDA_ENABLE=ON \
-DUSE_UNIFIED_MEMORY=ON \
-DUSE_ATS_MEMORY=OFF \
-DCMAKE_C_COMPILER=/usr/bin/gcc-12 \
-DCMAKE_CXX_COMPILER=/usr/bin/g++-12 \
-DENABLE_TESTS=ON"
Memory Model Configuration
The pipeline supports multiple CUDA memory management modes, which can
be configured at compile time. ATS Memory (-DUSE_ATS_MEMORY=ON) is
enabled by default. To use another memory model, you must first disable
ATS.
For a detailed explanation of these models, please refer to Section 3 of
the gpu_acceleration.md report.
Add fallbacks for ARMv8a to make it compile
The current code, on ARM, uses ARMv8.1-A RDM instructions. Add a
fallback for processors that do not have this instruction set.
Add some specific compile options for this platform.
Add debian 12 to the list of architectures.
For now, test in the following configuration:
- 16 parallel channels
- channel length of 32 and 128
- with 61440 and 122880 samples
- 12 trials per each test (due to CUDA kernel loading delay in first iterations)
- multiple MIMO configurations: 2TX - 2/4/8/32 RX, 2/4/8/32 TX - 2RX
This commit introduces a new, configurable benchmark,
`test_channel_scalability`, designed to measure the performance and
scalability of the CUDA channel simulation pipeline under various
conditions.
This benchmark provides several key features:
- It supports multiple GPU execution models, including a high-throughput
"batch" mode, an asynchronous "stream" mode, and a "serial" mode for
baseline measurements.
- It includes an optional interference simulation mode, activated by the
`--sum-outputs` flag, which sums the outputs of multiple parallel
channels.
- Simulation parameters (MIMO configuration, signal length,
channel length, and batch size) are configurable via command-line
arguments.
- It runs the full simulation pipeline on both the CPU and the GPU,
reporting the average execution time for each and calculating the
overall speedup.
This commit extends the CUDA API with new functions designed for
high-throughput scalability testing and advanced concurrency.
Key additions include:
- Batched versions of the kernels (`..._batched`) that use the
`blockIdx.z` grid dimension to process many independent channel
simulations in parallel.
- A C-callable wrapper, `run_channel_pipeline_cuda_batched`, to
orchestrate the execution of these new kernels.
- A "streamed" version of the pipeline,
`run_channel_pipeline_cuda_streamed`, which accepts a
`cudaStream_t` as an argument. This allows the calling
application to manage the execution stream, enabling overlap
with other GPU or CPU tasks.
This commit adds a performance benchmark for the end-to-end channel simulation pipeline, named `test_channel_simulation`. Its methodology is as follows:
- It systematically iterates through a matrix of test cases, varying
MIMO configuration (Tx/Rx antennas), signal length, and channel
length.
- For each case, it runs both the full CPU pipeline (`multipath_channel_float`
followed by `add_noise_float`) and the single `run_channel_pipeline_cuda`
function.
- It measures the average execution time for both implementations over
many trials and calculates the resulting speedup.
This provides a performance characterization of the GPU pipeline across different workloads and directly compares it to the CPU baseline.
This commit introduces the main C-callable pipeline function,
`run_channel_pipeline_cuda`, located in a new `channel_pipeline.cu`
file.
This function serves as the primary entry point for the GPU channel
simulation. It orchestrates the entire sequence of operations:
- Manages Host-to-Device data transfers for the input signal and
channel coefficients.
- Launches the `multipath_channel_kernel` and the
`add_noise_and_phase_noise_kernel` in the correct order.
- Manages the Device-to-Host data transfer for the final output signal.
- Synchronizes to ensure completion before returning.
This commit adds a new standalone benchmark, `test_noise`, to measure
and compare the performance of the CPU and CUDA implementations of noise
generation.
The benchmark's methodology is as follows:
- It iterates through various configurations, including different
numbers of receive antennas and signal lengths.
- For each configuration, it runs both the CPU (`add_noise_float`)
and CUDA (`add_noise_cuda`) functions multiple times to get a stable
average execution time.
- It prints a formatted table comparing the CPU and GPU latencies and
calculates the resulting speedup.
This commit adds the CUDA implementation for adding Additive White
Gaussian Noise (AWGN) and phase noise to the signal. The code is
located in phase_noise.cu.
- The `add_noise_and_phase_noise_kernel` uses the NVIDIA cuRAND
library for efficient parallel random number generation.
- Helper functions are included to create, initialize, and destroy
the cuRAND states required by the kernel.
- Placeholder for a C-callable wrapper, `add_noise_cuda`, is also
provided.
This commit adds a new standalone unit test, `test_multipath`, to
validate the CUDA implementation of the multipath channel.
The test performs the following steps:
- Generates a random input signal and channel model.
- Runs the CPU version (`multipath_channel_float`) to get a baseline result.
- Runs the CUDA version (`multipath_channel_cuda`) with the same inputs.
- Compares the two outputs by calculating the Mean Squared Error (MSE)
and ensures it is below a small tolerance.
This commit introduces the CUDA implementation of the multipath channel
model in `multipath_channel.cu`.
- Implements `multipath_channel_kernel` using shared memory for
efficient, high-performance convolution.
- Provides a C-callable wrapper, `multipath_channel_cuda`, to
orchestrate the full pipeline of data transfers and kernel
launches.
- The wrapper includes support for multiple memory models (Explicit
Copy, Unified Memory, ATS) via preprocessor directives to adapt to
different build configurations.
- Adds a `interleave_channel_output_cuda` utility to convert signal
data from the CPU's planar format to the GPU's interleaved format.
This commit refactors the CPU-based channel model for improved reusability and extends it with single-precision floating-point support.
This serves as a performance and correctness baseline for the new CUDA implementation.
Key changes include:
- The original double-based multipath_channel function is refactored to remove hardcoded antenna dimensions from its signature. It now accepts dynamically sized arrays, making it more flexible for use in simulators like dlsim and ulsim.
- A new multipath_channel_float function is introduced to operate on float data types, matching the GPU's native format.
- A corresponding add_noise_float function is also added to complete the floating-point CPU pipeline.
- The new float-based functions are designed to work with an interleaved IQ sample format ([I, Q, I, Q]), which is more suitable for vectorized (SSE) and GPU processing.
This commit adds the initial infrastructure for building accelerated simulation components.
- Adds the CUDA_ENABLE option and logic to find the CUDA toolkit.
- Adds the CHANNEL_SSE option to enable SSE-specific code paths.
- Sets required properties on the SIMU target to allow linking with CUDA-compiled objects.
- Creates the initial oai_cuda.h header for the public API.
Removing the duplicate loop in ULSCH power computation
- Removing the duplicate loop in ULSCH power computation.
- The logs obtained are as follows:
[NR_MAC] UE dc65: 134.11 Generating RA-Msg2 DCI, RA RNTI 0x113, state 1, preamble_index(RAPID) 42, timing_offset = 5 (estimated distance 195.3 [m])
[PHY] PUSCH not detected in 134.17 (307,302,50)
[PHY] PUSCH not detected in 134.17 (311,309,50)
[NR_MAC] 135 4: RA RNTI 41c5 CC_id 0 Scheduling retransmission of Msg3 in (135,8)
[NR_MAC] 135 4: RA RNTI a3cc CC_id 0 Scheduling retransmission of Msg3 in (135,8)
[PHY] PUSCH not detected in 134.18 (310,312,50)
[NR_MAC] 135 5: RA RNTI dc65 CC_id 0 Scheduling retransmission of Msg3 in (135,9)
[PHY] PUSCH not detected in 135.8 (309,309,50)
[PHY] PUSCH not detected in 135.8 (313,308,50)
[NR_MAC] 13515: RA RNTI 41c5 CC_id 0 Scheduling retransmission of Msg3 in (135,19)
[NR_MAC] 13515: RA RNTI a3cc CC_id 0 Scheduling retransmission of Msg3 in (135,19)
[PHY] PUSCH not detected in 135.9 (308,300,50)
[NR_MAC] 136 4: RA RNTI dc65 CC_id 0 Scheduling retransmission of Msg3 in (136,8)
[NR_PHY] [RAPROC] 135.19 Initiating RA procedure with preamble 6, energy 19.1 dB (I0 63, thres 120), delay 4 start symbol 0 freq index 0
[PHY] PUSCH not detected in 135.19 (310,310,50)
[PHY] PUSCH not detected in 135.19 (312,310,50)
[NR_MAC] 135.19 UE RA-RNTI 010b TC-RNTI 0888: initiating RA procedure
[NR_MAC] UE 0888: Sync beam index 0
[NR_MAC] UE 0888: Msg3 scheduled at 136.17 (136.10 TDA 2) start 0 RBs 8
[NR_MAC] UE 0888: 136.10 Generating RA-Msg2 DCI, RA RNTI 0x10b, state 1, preamble_index(RAPID) 6, timing_offset = 4 (estimated distance 156.3 [m])
- For the same scenario, develop branch gives exactly the same result. When
there is no PUSCH, the power measured for ULSCH and noise are practically
the same. Furthermore, the value in develop branch is also approximately
310 for the same noise level.
Prior to this commit, noise power estimation could be zero because of a
call to clearArray() in gNB_I0_measurements(). This is problematic, as
this can lead to a noise power of 0 if all symbols in a RB are used,
which in turn leads to a spike in SNR.
To avoid this, use an intermediate array to store noise power, and only
update n0_subband_power if not all RBs are used (i.e., we can detect
noise power). Further, use an exponential moving average to smoothen
noise estimation.
Fixes: fb4235fd50 ("changes in PUCCH0 SNR measurement, testing for
PUCCH power control")
semi-manual remove of not used #define commands
As i was upset to see all these #define with no code under, i made a
global pass to remove the obvious cases semi-manual remove of not used
bodies
manual script, then a lot of manual review
grep -IRs "#define" ../openair* ../common/* ../executables/ ../nfapi/ ../radio/ | \
fgrep -v '(' | fgrep -v '//' |awk '{print $2}' | egrep -v "#define *$n"| \
while read n ; do
grep -IRs $n ../openair* ../common/* ../executables/ ../nfapi/ ../radio/ | grep -v "#define *$n" | grep -q $n || echo $n;
done
will give a decent list of #define never used. Then, I think we should
keep lists of # define when it comes from standards, even if the code
doesn't use it right now
NR UE: add support for multiple RF frontends
This MR adds basic support for multiple RF-frontends at the UE.
There are multiple reasons why we might want this:
1. There might be different antennas needed for different bands (e.g. NTN or
TN antennas). These antennas might be connected to different RF-frontends.
In case of Handover, the UE needs to dynamically switch between these
RF-frontends.
2. Each rf-simulator connection carries baseband I/Q samples. To be able to
perform a handover between two cells at different frequencies, there must
be two rf-simulator connections, as the baseband channels should not
interfere and thus cannot simply be added.
3. When we want to support multiple UE simulation within one instance of
nr-uesoftmodem, and allow multiple cells and probably even handover between
these cells, we need either:
1. dedicated RF-frontends for each simulated UE, or
2. dedicated RF-frontends for each connected cell and dynamically assign
simulated UEs accordingly.
This MR implements what is needed for 1., 2. and 3.1.
This feature shall allow in future to simulate an arbitratry number of UEs connected to an other arbitrary number of cells.
Therefore each RF-frontend (also called RU) needs to be configured for one specific cell.
In case of handover of a UE from one cell to another cell, it needs to switch RUs accordingly (TODO).
There has to be a 1-to-1 mapping between RUs and cells.
Each UE will be assigned to one of the defined cells.
Initially all UEs are assigned to cell 0.
UE support to send CSI report on PUSCH
Earlier work on UCI on PUSCH implemented only ACK/NACK. This MR extends that
to send CSI report too.
This branch is verified with MATLAB implementation for multiplexing CSI part 1
and part 2 on PUSCH. It is also verified with srsRAN gNB which successfully
decodes CSI part 1 on PUSCH.
Fix RSRP overflow
If UE L1 measure an RSRP = 0 it would report to L2 and RSRP value of -INT_MAX
dBm causing overflow in the qsort to determine the best RSRPs
The global variable rx_gain_off was always 0.0, as it was not even modified by the NR UE command line parameter --ue-rxgain-off.
That command line parameter modified only a parameter in the struct nrUE_params_t, which was not used at all and is removed in this commit, too.
Also, the global variable rx_gain_off was just added to rx_total_gain_dB and subtracted from it again in nr_rf_card_config_gain().
So we simplify that function slightly, too.
Robert Schmidt