DOCSEARCHbyAlgolia
Submit Docs

NVIDIA Aerial CUDA-Accelerated RAN SDK

repository·main·Indexed 19 days ago

https://github.com/nvidia/aerial-cuda-accelerated-ran

An SDK for building AI-native wireless networks featuring GPU-accelerated implementations of 5G Physical (L1) and MAC (L2) layers. The SDK includes tools for 5GModel regression testing via MATLAB, build profile management, and utility scripts for converting ORAN CUS fronthaul PCAP files to cuPHY tensors, analyzing test vector disk usage, and extracting test vector parameters.

Tokens
57.1K
Snippets
139
Records
201
Agent score
64%

What's inside NVIDIA Aerial CUDA-Accelerated RAN

  1. Overview of Aerial SDK TestBenches

    main

    The testBenches directory provides tools for testing and benchmarking Aerial SDK components. The directory structure includes:

    • cubb_gpu_test_bench/: A GPU-only performance testbench.
    • perf/: Python helper scripts for driving cubb_gpu_test_bench (configuration, execution, and visualization).
    • chanModels/: A library for 3GPP 38.901 channel models (link-level TDL/CDL and system-level UMa/UMi/RMa).
    • phase4_test_scripts/: Automation scripts for end-to-end cuBB tests (CPU+GPU).

  2. Overview of the RU Emulator Module

    main

    The RU (Radio Unit) Emulator is a software component used to simulate 5G Radio Unit behavior in controlled testing environments. Instead of live wireless data, it uses static I/Q samples from test vector files to generate realistic network traffic. It is designed for both TDD (Time Division Duplex) and FDD (Frequency Division Duplex) multicell scenarios.

    Key Use Cases

    • Network Testing: Simulate RU behavior without physical wireless hardware.
    • Protocol Validation: Validate Control Plane and User Plane message handling in 5G fronthaul networks.
    • Performance Analysis: Measure throughput, latency, and timing characteristics.
    • DU Development: Provide a stable environment for Distributed Unit (DU) development.

  3. Overview of the cuPHY Driver

    main

    The cuPHY driver acts as the orchestrator between the GPU, the Front-Haul (FH) interface, and the L2 adapter. It manages the execution of physical layer tasks at the slot level.

    Key Responsibilities:

    • Task Orchestration: Processes L2 slot commands from the L2 adapter to launch cuPHY and FH library tasks.
    • L2 Communication: Uses the L2 adapter FAPI message handler library to send cuPHY outputs (such as CRC indications, UCI indications, and measurement reports) back to L2.
    • GPU Management: Configures and initiates Downlink (DL) and Uplink (UL) cuPHY tasks, which trigger CUDA kernels on the GPU.
    • User Plane (u-plane) Data Handling: Controls CUDA kernels for transmitting and receiving u-plane packets to/from the NIC. This includes handling re-ordering and decompression for UL packets, and compression for DL packets.
    • Front-Haul (FH) Coordination: Interacts with the FH interface using an ORAN-compliant FH library to coordinate the transmission of FH control plane (c-plane) packets via DPDK library calls (CPU-initiated).

  4. Overview of NVIDIA Aerial™ CUDA-Accelerated RAN

    main

    NVIDIA Aerial™ CUDA-Accelerated RAN is a software development kit (SDK) designed for building, training, simulating, and deploying AI-native wireless networks. It provides GPU-accelerated components for the 5G physical and MAC layers.

    Key components include:

    • cuPHY (GPU-Accelerated 5G PHY): CUDA-based physical layer processing (LDPC, Polar coding, MIMO, modulation/demodulation).
    • cuMAC (GPU-Accelerated MAC Scheduler): High-performance L2 scheduler for resource allocation.
    • pyAerial (Python API): Python bindings for AI/ML research and integration with frameworks like TensorFlow and Sionna.
    • 5GModel: MATLAB-based 5G waveform generation and test vector creation.
    • Containerized Environment: Docker-based development and deployment.

  5. Calibrate 3GPP channel models against reference data

    main

    The Aerial SDK allows you to validate its channel model implementations (specifically UMa and UMa-AV/ISAC) against 3GPP TR 38.901 specifications. The calibration process involves three main steps:

    1. Channel Generation: Creating channel realizations in H5 format using the sls_chan_ex executable.
    2. Statistical Analysis: Extracting metrics such as coupling loss, delay spread, angle spreads, and K-factor.
    3. CDF Comparison: Comparing the Cumulative Distribution Functions (CDFs) of the generated data against 3GPP reference curves.

    Supported models include:

    • TDL (A/B/C): GPU version, calibrated.
    • CDL (A/B/C): GPU version, calibrated.
    • UMa: CPU/GPU versions, calibrated.
    • UMi: CPU/GPU versions, not calibrated.
    • RMa: CPU/GPU versions, not calibrated.
    • UMa-AV (ISAC): CPU version, calibrated.

  6. Convert ORAN CUS fronthaul PCAP files to cuPHY tensors

    main

    The pcap_to_tensor.py script extracts user data (IQ) samples from ORAN CUS fronthaul PCAP capture files. It produces a separate output file containing the raw IQ data buffer for every slot.

    To handle repeating slots that share the same FrameId, SubframeId, and SlotId, the script uses the U-plane packet RX timestamp to differentiate them.

    Configuration is managed via a YAML file. The script uses config.yaml by default if no other configuration is provided.

    python3 pcap_to_tensor.py /tmp/example.pcap --config ~/my_config.yaml

  7. Understand the cuPHY directory layout

    main

    The cuPHY SDK is organized into several functional directories:

    • src/: Core library implementation.
      • src/cuphy/: Main CUDA/C++ implementations and public APIs for 5G NR physical-layer functions and pipelines.
      • src/cuphy_channels/: Channel level aggregations used by cuPHY-CP and examples/tests.
      • src/cuphy_hdf5/: HDF5-based utilities for reading/writing test vectors and configuration data.
    • examples/: Reference implementations (e.g., pdsch_tx, pusch_rx_multi_pipe, srs_rx_pipeline, prach_receiver_multi_cell).
    • test/: Unit and component tests, including the cuphy_unit_test.sh helper script.
    • nvlog/: Low-overhead, high-throughput structured logging utility.
    • docs/: Doxygen configuration and documentation assets.
    • cmake/: CMake utilities and toolchain files for standalone builds.
    • util/: Supporting utilities like MATLAB integration and performance collection scripts.

  9. Overview of Channel Model types

    main

    The chanModels directory provides 3GPP 38.901 compliant wireless propagation simulations:

    • System Level Channel Model (SLS): Implements statistical models (UMa, UMi, RMa). Supports GPU-accelerated computation via CUDA kernels or CPU-only mode. Located in chanModels/src/sls_chan_src/.
    • Link Level Channel Model (TDL): Tapped Delay Line models (TDL-A, B, C) for fast fading and configurable Doppler effects. Located in chanModels/src/tdl_chan_src/.
    • Link Level Channel Model (CDL): Clustered Delay Line models (CDL-A through E) supporting LOS and NLOS scenarios. Located in chanModels/src/cdl_chan_src/.
    • Supporting Components: Includes OFDM Modulator/Demodulator (ofdm_src), Gaussian Noise Adder (gauNoiseAdder), and generic Fading Channels.

  10. Compare TensorRT execution modes: Graph vs Stream

    main

    The integration supports two execution modes, which differ in how the pre/post conversion kernels are invoked:

    Graph Mode (Non-Stream)

    In this mode, pre/post conversion kernels are integrated as nodes within a larger CUDA graph.

    • Construction: A TrtEngineChestGraphMgr manages the graph. It uses ChestPrePostEnqueueTensorConversion::setup to obtain kernel launch configurations (puschPrePostTensorConversionLaunchCfg_t). The graph includes a pre-conversion kernel node, a child graph node for TensorRT inference, and a post-conversion kernel node.
    • Execution: setSecondaryNodeStatus uses cuGraphExecKernelNodeSetParams to assign the actual kernelNodeParamsDriver (containing the kernel function pointers) to the executable graph (CUgraphExec).

    Stream Mode

    In this mode, kernels are launched as distinct CUDA kernel calls on a stream, bracketing the TensorRT execution.

    • Flow: TrtEngineChestStream::launchKernels calls m_trtEngine->run(stream). This triggers preEnqueueConvert(...) (launching prepareChestMlInputsKernel), followed by m_context->enqueueV3(cuStream) for inference, and finally postEnqueueConvert(...) (launching extractChestMlOutputsKernel).

  11. Understand the C-Plane processing flow

    main

    The C-Plane cores handle message reception, resource allocation, and timing coordination. For Uplink (UL) C-Plane processing, the flow is as follows:

    1. Message Reception: Receive O-RAN C-Plane messages from the DU.
    2. Test Vector Correlation: Correlate incoming C-Plane time and frequency ranges against stored test vectors.
    3. Section Processing: Handle Section Type 1 (non-PRACH) and Section Type 3 (PRACH) messages.
    4. U-Plane Packet Preparation: Prepare U-Plane packets using I/Q samples from test vectors.
    5. Timing Offset Management: Apply configurable offsets (ul_u_plane_tx_offset for standard or ul_u_plane_tx_offset_srs for SRS).
    6. TXQ Enqueueing: Enqueue packets into transmission queues based on T0 timing + offset.

  12. What the SCF L2 Adapter does

    main

    The SCF L2 Adapter serves as the interface between the L1 (Physical Layer) and L2 (Data Link Layer). Its primary responsibilities are:

    1. FAPI Message Handling: Managing the FAPI (Flexible API) messages exchanged between the L1 and L2 layers.
    2. Task Translation: Translating incoming FAPI messages into specific cuPHY tasks to drive the CUDA-accelerated physical layer operations.