从真实 5G 网络采集 AI 训练数据：基于 NVIDIA Aerial Data Lake 构建 AI-RAN 数据平台

从真实 5G 网络采集 AI 训练数据：基于 NVIDIA Aerial Data Lake 构建 AI-RAN 数据平台

利用 DGX Spark、O-RAN O-RU、SRS 信道估计与 ClickHouse，让无线网络从通信实验平台升级为 AI 数据采集平台。

一、AI-RAN 研究面临的一个关键问题：真实无线数据从哪里来？

近年来，AI-RAN 正在成为 5G-Advanced 和 6G 研究中的重要方向。

从 AI 辅助信道估计、神经接收机（Neural Receiver），到波束管理、无线资源调度优化和无线网络数字孪生，越来越多的研究工作开始尝试将人工智能引入无线接入网。

然而，开展 AI-RAN 研究并不只是需要 GPU 和 AI 算法。

一个经常被忽视的问题是：

用于训练、测试和验证 AI 算法的真实无线数据，应该从哪里获得？

在传统无线通信研究中，研究人员通常采用 MATLAB、Sionna 或其他仿真平台生成信道数据。

这类方法具有较好的可控性，可以调整 SNR、多径衰落、移动速度、天线数量等参数。

但仿真环境与真实无线网络之间仍然存在差异。

真实系统可能受到射频非线性、频偏、定时误差、硬件实现、外部干扰以及复杂传播环境等因素的影响。

如果 AI 算法只在仿真数据上训练，其在真实无线链路中的表现仍然需要进一步验证。

因此，如何从实际运行的 5G 网络中提取无线物理层数据，正在成为 AI-RAN 研究的重要基础工作。

NVIDIA Aerial Data Lake 为这一需求提供了一种值得关注的技术方案。

二、什么是 NVIDIA Aerial Data Lake？

NVIDIA Aerial CUDA-Accelerated RAN（ACAR）利用 NVIDIA GPU 加速无线接入网物理层处理。

在此基础上，NVIDIA 提供了 Data Lake 数据采集能力，用于从 O-DU 内部获取无线通信运行数据。

它并不是传统意义上只存储业务流量的数据库。

Aerial Data Lake 的核心价值，在于能够获取无线物理层处理过程中的中间数据与测量结果。

这些数据可用于故障调试、性能分析、离线算法研究，以及 AI/ML 模型训练。

根据 NVIDIA 官方文档，Data Lake 主要包含三个部分：

1. Data Collection App（DCA）：运行在 CPU 上，负责数据采集。
2. Data Lake Database（DLDB）：存储采集的数据。
3. DLDB API：提供数据查询与访问接口。

数据可从 GPU 物理层处理流水线中导出，经过内存缓冲后写入 ClickHouse 数据库。

这意味着研究人员不必完全依赖外部 SDR 设备抓取无线信号，而可以在支持的 Aerial 系统中，从实际运行的 5G 基站获取部分物理层数据。

三、系统架构：从 O-RU 到 AI 数据集

对于一套基于 DGX Spark、OAI 和 O-RAN O-RU 的实验平台，可以采用如下数据采集架构。

            5G Android UE
                  |
                  | NR Uu
                  v
             O-RAN O-RU
                  |
                  | eCPRI / Split 7.2x
                  v
       +-----------------------+
       |   NVIDIA DGX Spark   |
       |                       |
       |  NVIDIA Aerial cuPHY  |
       |           |           |
       |           v           |
       |       Data Lake       |
       |       Collector       |
       |           |           |
       |           v           |
       |       ClickHouse      |
       |                       |
       |  OAI MAC/RRC          |
       +-----------------------+
                  |
                  v
               OAI 5GC

           Data Lake API
                  |
                  v
         Python / Jupyter
                  |
           +------+------+
           |             |
           v             v
       数据分析      AI 模型训练
           |             |
           v             v
        可视化       Sionna / PyTorch

在该架构中，O-RU 负责无线信号收发，Aerial cuPHY 负责 GPU 加速物理层处理，OAI 提供上层协议栈。

Data Lake 则负责将支持采集的数据保存下来，供后续分析使用。

实验人员可以通过 Python、Jupyter Notebook 或其他数据分析工具访问采集结果。

需要注意，数据采集能力和可用字段取决于 Aerial 软件版本、配置与具体数据路径，并不是所有物理层内部变量都会自动导出。

四、Aerial Data Lake 能采集哪些数据？

根据 NVIDIA 当前的 Aerial CUDA-Accelerated RAN 文档，Data Lake 支持多种上行无线数据。

数据类型	ClickHouse 表	主要用途
Fronthaul IQ	fh	分析上行前传 IQ 样本
PUSCH / FAPI	fapi	查看上行调度及接收元数据
PUSCH Channel Estimate	hest	分析 DMRS 信道估计
SRS IQ	srs_iq	分析 SRS 接收信号
SRS Measurements	srs	查看 SNR、ToA 等测量
SRS Channel Estimate	srs_hest	分析 SRS 信道估计矩阵

这些数据对于通信 AI 研究具有不同的意义。

4.1 Fronthaul IQ：研究真实无线接收信号

fh 数据表保存前传上行 IQ 相关数据。

研究人员可以在满足数据格式和同步条件的情况下，利用 IQ 样本进行离线信号分析。

例如：

• 星座图与信号特征分析；
• 噪声与干扰特性研究；
• 无线信道统计分析；
• 接收机算法验证；
• 仿真信号与真实信号对比。

不过，O-RAN 前传 IQ 与普通 SDR 采集的原始时域 IQ 并不完全等价。

必须结合前传压缩方式、资源映射、天线端口和符号配置正确解析，才能得到具有明确物理意义的数据。

4.2 PUSCH 信道估计：AI 接收机的重要数据来源

hest 保存与 PUSCH DMRS 相关的信道估计。

在传统接收机中，信道估计用于补偿无线信道对接收信号产生的影响。

对于 AI 接收机研究，这些估计值可作为分析或辅助训练数据。

例如，可以研究：

• 不同 SNR 下的信道估计误差；
• 多天线信道相关性；
• 信道随时间和频率的变化；
• 神经网络信道估计方法；
• 传统信道估计算法与 AI 算法的性能差异。

需要强调，传统算法产生的信道估计不等同于理想真实信道（Ground Truth）。

如果使用它作为机器学习标签，应明确标签误差和数据生成方法。

4.3 SRS：面向 6G 信道感知与定位研究

SRS 是 5G NR 上行链路的重要参考信号。

对于研究无线信道测量、波束管理和定位的实验室，SRS 具有重要价值。

Aerial Data Lake 支持保存 SRS IQ、信道估计及相关测量数据。

在具备相应能力的版本中，可进一步分析：

• Wideband SNR；
• Per-RB SNR；
• Time of Arrival（ToA）；
• SRS Resource Configuration；
• SRS Channel Estimates；
• 不同接收天线之间的信道差异。

这些信息为无线信道研究提供了数据基础。

例如，通过观察不同时间、天线和频率资源上的 SRS 信道估计，可以分析无线信道变化趋势。

对于多 TRP 定位研究，还可以探索基于 SRS 到达时间的测量方法。

不过，单纯获得 ToA 或 SRS 信道估计，并不代表已经具备完整的 UL-TDOA 定位能力。

实际定位还需要多站点时间同步、射频链路时延校准、测量关联以及位置估计算法。

五、实际操作：使用 ClickHouse 检查数据采集情况

完成 Aerial Data Lake 的配置和启动后，可以通过 ClickHouse 检查数据。

假设 ClickHouse 运行在 Docker 容器中：

docker ps

找到对应容器后，进入数据库：

docker exec -it my-clickhouse-server \
  clickhouse-client

首先查询 Data Lake 相关数据表：

SELECT
    database,
    name,
    engine,
    total_rows
FROM system.tables
WHERE name IN (
    'fh',
    'fapi',
    'hest',
    'srs',
    'srs_hest',
    'srs_iq'
)
ORDER BY name;

如果采集正常，可以观察到部分数据表的行数随实验运行而增长。

对于采用 MergeTree 的数据表，system.tables.total_rows 可以用于快速查看存储规模；进行精确记录数统计时，建议根据需要使用 count()。

接下来，可以查看不同数据表的存储空间：

SELECT
    table,
    formatReadableSize(sum(bytes_on_disk)) AS size
FROM system.parts
WHERE active
  AND table IN (
      'fh',
      'fapi',
      'hest',
      'srs',
      'srs_hest',
      'srs_iq'
  )
GROUP BY table
ORDER BY sum(bytes_on_disk) DESC;

这能够帮助工程师了解不同采集数据对 SSD 的占用情况。

特别是 IQ 和信道估计数据，在长时间连续采集时可能快速增加，应当制定合理的数据保留策略。

六、如何启用 SRS 数据采集？

根据 NVIDIA Aerial 的 Data Lake 文档，数据库写入与数据类型选择需要通过相关配置控制。

参考配置如下：

cuphydriver_config:
  data_config:
    datalake_db_write_enable: 1
    datalake_address: localhost
    datalake_data_types:
      - fh
      - pusch
      - hest
      - srs_iq
      - srs
      - srs_hest

上述字段来自 Aerial 近期版本的数据采集文档，实际配置时应与当前使用的软件版本及配置文件结构核对。

其中：

• datalake_db_write_enable 控制是否写入数据库；
• datalake_address 指定数据库地址；
• datalake_data_types 选择需要保存的数据类型。

对于 SRS 采集，还必须确认 gNB 确实配置了 SRS 资源，并且 UE 实际发送了 SRS。

如果 fh、fapi 和 hest 表存在数据，而 srs、srs_hest 和 srs_iq 始终为空，不能直接认定是数据库故障。

建议依次检查：

1. UE 是否具备有效的 SRS 配置；
2. 是否存在实际的 SRS 上行发送；
3. Aerial 物理层是否完成对应 SRS 处理；
4. Data Lake 是否启用了 SRS 数据库写入；
5. 数据采集缓冲区是否出现丢弃；
6. 对应版本是否支持所需的数据字段。

需要特别注意，Data Lake 内存采集与数据库写入是两个不同的环节。

即使 E3 Agent 可以访问某类数据，也不一定说明该数据已经写入 ClickHouse。

七、从数据采集到 AI 训练集

采集到数据之后，下一步不是直接把所有 ClickHouse 表导入神经网络。

真正可复现的 AI 数据集，需要解决数据关联、数据清洗和标签设计三个问题。

7.1 跨数据表关联

Aerial Data Lake 的不同表包含 SFN、Slot、CellId 和时间戳等关联字段。

可以利用这些信息，将同一无线时间资源中的数据关联起来。

例如，把某个 Slot 对应的：

• Fronthaul IQ；
• PUSCH 调度信息；
• 信道估计；
• SRS 测量结果；

组织成统一的样本记录。

跨表关联时，需要注意同一 Slot 可能包含多 UE、多天线或多个数据块。

因此，不能简单地仅使用 SFN 和 Slot 进行一对一关联，还需要结合 RNTI、CellId、资源配置和数据结构判断对应关系。

7.2 设计 AI 数据集格式

对于离线研究，可以将经过解析的样本保存为 Parquet、HDF5 或 NumPy 等格式。

例如，一个用于无线信道研究的数据集可以包含：

aerial-dataset/
│
├── metadata/
│   ├── experiment.json
│   └── configuration.json
│
├── iq/
│   ├── capture_001.h5
│   └── capture_002.h5
│
├── channel/
│   ├── hest_001.h5
│   └── hest_002.h5
│
├── measurements/
│   └── metrics.parquet
│
└── labels/
    └── annotations.parquet

其中的 experiment.json 可以记录：

• Aerial 软件版本；
• GPU 与服务器平台；
• O-RU 型号；
• 频段和中心频率；
• 信道带宽与 SCS；
• 天线配置；
• UE 型号；
• 测量场景；
• 数据采集时间。

这样可以保证后续研究人员能够复现实验条件。

7.3 数据标签从哪里来？

不同 AI 任务需要不同的标签。

例如，对于无线信道分类任务，标签可能是 LOS/NLOS、场景类别或移动状态。

对于链路质量预测，可以使用未来一段时间内的测量值构造监督目标。

对于神经接收机训练，则可能需要已知发送符号、编码比特或经过可靠验证的参考结果。

这些标签不一定直接存在于 Aerial Data Lake 中。

因此，数据采集系统需要与实验控制、UE 状态记录或外部测量工具结合，才能构建完整的监督学习数据集。

八、E3 dApp：让 AI 能够实时获取无线数据

除了离线 Data Lake 数据库，NVIDIA Aerial 还提供面向 dApp 的 E3 接口能力。

在支持的版本中，dApp 可以通过 E3 Agent 订阅无线测量和物理层相关数据。

对于较小的测量值，例如 SNR、MCS 或时间戳，可通过消息字段传递。

对于 IQ 样本和信道估计等较大的数据，则可以利用共享内存引用，减少数据复制开销。

这种方式适合探索低时延 AI 推理应用。

例如：

无线信道质量预测

dApp 根据实时测量数据，利用训练好的模型预测未来短时间内的信道变化。

AI 辅助链路分析

利用历史 SRS 和 PUSCH 测量信息识别无线链路异常。

无线环境感知

对多天线信道特征进行分析，探索环境变化检测等研究任务。

AI 驱动网络控制

在具备受支持的控制接口并经过充分验证的情况下，研究如何将 AI 推理结果用于网络控制。

需要注意，dApp 能够读取某类数据，并不意味着它一定能够通过 E3 修改对应的无线参数。

控制能力取决于软件版本、Service Model 和实际实现，不应假设任意无线调度参数都可以直接由 dApp 控制。

九、如何保证数据采集不影响 5G 网络性能？

对于实时无线系统而言，数据采集本身也会消耗 CPU、内存和存储资源。

特别是在 DGX Spark 等统一内存平台中，物理层计算、数据库写入和 AI 数据处理可能共享部分系统资源。

如果采集负载过大，甚至可能反过来影响无线网络实时性。

因此，建议在实际部署中采用以下策略。

第一，合理规划 CPU 资源。

Data Lake 数据采集线程需要获得稳定的 CPU 执行时间。

如果与高负载的数据库、Docker 容器或其他计算任务争用 CPU，可能出现采集延迟和数据丢失。

第二，控制采集数据类型。

不一定每次实验都需要同时记录全部 IQ、信道估计和 SRS 数据。

可以根据研究目标选择必要的数据类型，减少额外负载。

第三，监控数据库写入压力。

当 ClickHouse 写入无法及时消耗采集缓冲区时，数据可能被丢弃。

因此，需要关注采集日志中的 Busy、Slow Start 或 Skip Slot 等异常信息。

第四，将实时处理与离线分析分离。

建议尽量避免在执行实时 5G OTA 测试时，同时启动高负载的 AI 模型训练任务。

更稳妥的实验流程是先采集数据，再利用空闲计算资源进行离线分析和训练。

对于追求更大吞吐量和更高稳定性的研究平台，还可以考虑将数据库与 AI 训练任务迁移到独立服务器。

十、从真实无线数据走向 6G AI-Native RAN

从更长期的研究方向来看，Aerial Data Lake 的意义不仅在于增加数据记录功能。

它为通信物理层与人工智能算法之间建立了一条可验证的数据通道。

传统无线通信系统更关注实时传输和协议处理。

而未来面向 AI 的无线系统，还需要考虑如何长期采集数据、构建训练集、验证模型，并在合适的时间尺度上更新 AI 算法。

例如，可以采用如下研究流程：

真实 5G 网络采集数据 → 数据清洗与标注 → 模型训练 → 离线评测 → 实验室推理验证 → 受控网络测试。

对于使用 NVIDIA Sionna 的研究团队，还可以将真实无线信道数据用于校准仿真模型，研究仿真环境与真实无线传播环境之间的差异。

但需要注意，真实信道数据的采集并不自动解决仿真到现实（Sim-to-Real）的泛化问题。

数据覆盖范围、场景多样性、标签质量以及模型训练方法，仍然是决定研究效果的重要因素。

十一、总结

AI-RAN 的发展不仅需要高性能 GPU 和先进的 AI 模型，还需要可靠、可复现、具有明确物理意义的无线通信数据。

NVIDIA Aerial Data Lake 提供了从真实无线接入网中获取部分物理层和协议层数据的技术路径。

通过 DGX Spark、O-RAN O-RU、OAI 和 ClickHouse，研究人员可以探索构建从真实无线信号采集到 AI 数据集管理的完整实验流程。

在此基础上，SRS 信道估计、PUSCH 测量、前传 IQ 和网络运行元数据，可以进一步服务于信道建模、AI 接收机、无线环境感知以及智能网络管理等研究方向。

未来 AI-RAN 实验平台的核心竞争力，可能不仅在于能够运行多快的 5G 网络，还在于能够从真实网络中获取多少高质量、可验证、可用于 AI 研究的数据。

从可运行的无线网络，到可持续产生科研数据的无线网络，这将是 5G/6G 实验平台值得关注的重要演进方向。

---

参考资料

1. NVIDIA Aerial CUDA-Accelerated RAN --- Data Lake 官方文档
2. NVIDIA Aerial Testbed --- Product Description
3. NVIDIA Aerial Sample Apps
4. E3 dApp Application Development Guide
5. E3 Shared Memory Data Representation
6. NVIDIA Sionna

本文基于 NVIDIA Aerial 公开技术资料整理，结合典型 5G/AI-RAN 实验场景进行工程分析。具体的数据类型、接口能力和配置字段应以所部署软件版本的官方文档为准。