限制#

已知限制#

  • cuPHY 库和二进制文件仅适用于合格平台上的 Linux 环境。

  • 支持的配置仅限于上面列出的配置。不支持其他配置，并且可能无法良好运行。

  • 多小区仅支持同构配置。

  • 可配置的 YAML 参数 enable_h2d_copy_thread、h2d_copy_thread_cpu_affinity 和 h2d_copy_thread_sched_priority 在 cuphycontroller YAML 文件中是可选的。如果这些参数不存在，代码将使用默认值并在 cuphycontroller 控制台上抛出异常“YAML invalid key:”。此异常消息对功能没有影响，可以忽略。

  • 从 22-2.4 版本开始，默认情况下需要启用 DL 的 GPU 启动通信（cuphycontroller config yaml 中的 gpu_init_comms_dl 标志）。该标志使 Aerial L1 内的功能能够调用 GPU 内核来准备和发送 DL 上的 U-Plane 数据包，而不是 CPU 启动通信 (gpu_init_comms_dl=0)，后者会执行 CPU 代码/消耗 CPU 周期来准备/发送 DL 上的 U-plane 数据包。

  • S-slot 中没有同时的 DL 和 UL 调度。但是，在与 O-RU 的 E2E 测试中支持仅 DL 的 s-slot。

  • 当给定小区的 FAPI 消息通过 nvipc 发送时，L1 期望通过 nvipc 显式通知（每个小区一次）。在多小区的情况下，需要从 L2 调用多个显式通知 API。当小区在给定时隙没有任何消息时，L1 期望发送虚拟 DL_TTI 和/或 UL_TTI.request，即 (nPDU = 0)，“每个小区”。如果通过使用 -DENABLE_L2_SLT_RSP=ON 编译 Aerial 启用了时隙响应功能，则此步骤是可选的。

  • 对于多小区操作，L2 可以通过 2 种方式向 L2Adapter 发送信令

    • 每个时隙单个事件：其中包含所有小区的 SCF FAPI 消息。在发送所有小区的消息后，通过每个时隙调用 nvipc notify(1) 一次来触发单个事件。

    • 每个小区单个事件：在发送给定小区的所有 FAPI 消息后，由 L2 发出信号。预计将为多个小区调用多个 nvipc notify(1)。调用 notify 的次数必须与活动小区的数量相同。在从 L2 接收到 START.req 后，小区被标记为活动状态。在这种情况下，L1 期望发送上述虚拟 DL_TTI 和 UL_TTI。这是默认行为。

    要选择操作模式，请在 yaml 中设置 ipc_sync_mode

    # Option 1: Sync per slot
ipc_sync_mode: 0
# Option 2: Sync per active cell
ipc_sync_mode: 1

    如果通过使用 -DENABLE_L2_SLT_RSP=ON 编译 Aerial 启用了时隙响应功能，则此设置不起作用，因为 L1 不期望来自 L2 的任何事件。

  • 小区生命周期管理

    • 所有小区都必须在任何小区启动之前配置。

    • 无在服务配置更新。

    • 在已配置（服务外）状态下接收到的 CONFIG.request 可用于仅更改 cuBB 快速入门指南的动态 PRACH 部分中指定的 PCI 和支持的 PRACH 参数。PHY 忽略 CONFIG.request 中接收到的任何其他 TLV。如果 CONFIG.response 指示成功，则仅更改 PCI 和支持的 PRACH 参数。所有其他参数保持与小区初始 CONFIG.request 中接收到的参数相同。

    • 在已配置（服务外）状态下的小区的 PHY 重新配置可能需要长达 40 毫秒才能完成（详见下文）。在此期间（大约 20 毫秒），在接收到 CONFIG.response 之前发生的任何小区的另一个 CONFIG.request 将返回带有错误代码“MSG_INVALID_STATE”的 CONFIG.response。不会为此错误发送 ERROR.indication。L2 需要等待接收到 CONFIG.response，然后才能为已配置状态下的另一个小区发送 CONFIG.request。

      • 如果 Aerial 配置为 4 个小区，并且 3 个小区正在服务中且正在运行数据，则 1 个小区（服务外）的重新配置可能需要大约 40 毫秒才能完成

      • 如果 Aerial 配置为 4 个小区，并且 3 个小区正在服务中且没有运行数据，则 1 个小区 (O-RU) 的重新配置可能需要大约 20 毫秒才能完成

    • 如果接收到的 CONFIG.response 带有错误代码“MSG_INVALID_CONFIG”，则重新配置不成功，并且小区仍使用初始 CONFIG.request 中接收到的配置。

    • 在重新配置期间，所有小区都不允许 UE 附着。

  • 动态 M-plane 参数

    • 当 OAM 发送 gRPC 消息以更改 M-plane 中的 MAC 地址时，它必须是有效的 O-RU MAC 地址。

  • nvlog_observer 和 nvlog_collect 在 23-1 中已弃用。

  • F13 测试用例在 23-2 中已弃用。

  • UCI.indication 中的早期 HARQ

    • 此功能仅在第一个 UL 时隙（x4 时隙）且所有早期 HARQ 位都驻留在符号 0-3 中时才受支持。

    • 带有早期 HARQ 的 UCI.Indication 将没有任何测量值。

    • 如果仅在 PUSCH 上调度 HARQ，则在启用此功能的情况下，在 PUSCH 的完整时隙处理后，不会向 L2 发送 UCI.indication。因此，该时隙的任何测量值都不会报告给 L2。

    • 如果 CSI 报告也与 HARQ 一起在 PUSCH 上调度，则带有早期 HARQ 的 UCI.Indication 将没有任何测量值。但是，在完成 PUSCH 的完整时隙处理后发送的 UCI.indication 将具有测量值。

    • 启用早期 HARQ 的一个约束是，这些 HARQ 位应完全驻留在 OFDM 符号 0-3 中。因此，驻留在 OFDM 符号 0-3 中的 HARQ 位将在第一个 UCI.indication 中（即，早期 HARQ 指示），而所有其他 HARQ 位将在随后的 UCI.indication 中（即，在完整时隙 PUSCH 处理完成后）。

  • 在不发出虚拟 config.req 的情况下进行多小区操作

    • 即使在初始阶段，L2 也应在两个 CONFIG.request 之间等待至少 40 毫秒，以便 L2 接收到 CONFIG.response。

    • L2 可以在 1 秒后重试给定小区的失败的 CONFIG.request。

  • 每个 GPU 具有单个 cuphycontroller 的多 L2

    • 所有 L2 实例的总小区数不能超过在 cuphycontroller yaml 中配置的 cell_group_num。

    • nvIPC 仅支持在 nvipc_multi_instances.yaml 中为多个 L2 实例定义的静态小区分配。在配置 L1 后，每个 L2 实例中的小区数量和小区映射都不能更改。

    • 支持每个 L2 实例中的动态小区启动/停止。不支持动态 L2 重启。L2 实例需要在连接到 L1 后保持 nvipc 实例。

  • 64T64R TDD 单小区

    • 不支持 PDSCH 资源分配类型 0 (RAT0)。

    • 不支持与天线切换相关的 SRS 报告（FAPI 222.10.04，表 3-133 - 信道 SVD 表示）。

已知问题#

  • 启用调试同步检查时，cuBB 测试用例 7600 报告 CRC 错误。问题仅在启用某些版本的同步调试工具时出现。

  • 在 22-2.4 版本之后，不再支持 CPU 启动通信 (gpu_init_comms_dl=0) 模式，建议不要为了测试目的而启用此模式。

  • 如果分配在 PUSCH 中是连续的，则最多支持 8 个 DMRS 端口。

  • SCHED_FIFO + 100% CPU 轮询线程导致系统在 5.4.0-65-lowlatency 内核上挂起。解决方案是以下之一

    • 配置内核选项 CONFIG_RCU_NOCB_CPU=y，重新编译并安装内核。

    • 将主机系统升级到 5.15.0-71-lowlatency 或更高版本。

  • Grace Hopper 上的 CUDA 应用程序

    • Grace Hopper 平台上的 CUDA 应用程序需要 ATS 支持。目前，当启用 IOMMU 直通时，arm64 平台上未启用 ATS。

  • Grace Hopper 上的 NIC 字符串转换问题

    • 在 K8s pod 中处理动态 CPU 核心分配时，我们需要解析和转储 cuphycontroller config yaml 文件。在 Grace Hopper 上，nic: 0000:01:00.0 将转换为 nic: 60.0。这是因为 PCIe 地址可能会根据“https://yaml.org/type/int.html”被解释为 60 进制整数。解决方法是显式告诉 yaml 解析器将 PCIe 地址解释为字符串，方法是在 pcie 地址周围加上单引号或在 pcie 地址前加上 !!str，例如，nic: ‘0000:01:00.0’ 或 nic: !!str 0000:01:00.0。

    From
   sed -i "s/nic:.*/nic: 0000:01:00.0/" ${cuBB_SDK}/cuPHY-CP/cuphycontroller/config/cuphycontroller_P5G_FXN.yaml
to
   sed -i "s/nic:.*/nic: ‘0000:01:00.0’/" ${cuBB_SDK}/cuPHY-CP/cuphycontroller/config/cuphycontroller_P5G_FXN.yaml
   (or sed -i "s/nic:.*/nic: \!\!str 0000:01:00.0/" ${cuBB_SDK}/cuPHY-CP/cuphycontroller/config/cuphycontroller_P5G_FXN.yaml)

  • 当使用多个 L2 运行 8C Peak (59/59b/59c) 测试用例时，存在已知问题（DL C-plane 发送错误）。

  • 以下测试用例未通过。它们可能是功能问题或测试框架问题

信道

测试用例

功能

PDSCH

3881

64TR

PUSCH

7600

多个 CSIP2
在本页中