---
service: "Publicasta"
schema_version: "1.0"
article_id: 840
title: "OCUDU 26.10 带来卫星 5G，也把开放 RAN 的互操作性推向更严苛的测试"
language: "zh"
default_language: "en"
canonical_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=zh"
json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=zh"
api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=zh"
channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar"
channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-10-09T06:42:14+00:00"
updated_at: "2026-10-09T06:42:14+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=ar"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=ar"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=de"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=de"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=en"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=en"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=es"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=es"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=fr"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=fr"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=pl"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=pl"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=ru"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=ru"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=zh"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=zh"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=zh"
---

# OCUDU 26.10 带来卫星 5G，也把开放 RAN 的互操作性推向更严苛的测试

> OCUDU 26.10 加入 Release 17 NTN、8T8R 天线、定位、安全改进和早期 Split 7.2b 实现。它适合具备设备与测试能力的团队开展实验，但发布说明也清楚表明：这仍应被当作基础设施来验证，而不是安装即用的成品网络。

OCUDU 26.10 是一项很容易被误读的开源版本。它的重点功能听起来像是同时回答了电信领域几个棘手问题：卫星连接、更高阶 MIMO、波束管理、定位、开放前传以及更强的安全能力。项目也正从早期公开版本，转向 Linux Foundation 治理下较为可预期的每年 4 月和 10 月发布节奏。

 ![配备5G无线设备和卫星链路测试装置的电信实验室，展现开放式RAN互操作性工作](https://publicasta.com/storage/projects/10/pages/840/2026/10/3f4611c8-f80d-4020-abfe-d61d78e98a2f.webp)

 这使得本次版本很重要，但并不意味着它可以直接替代商用无线接入网。更准确的理解是：OCUDU 26.10 是一个严肃的开源 5G CU/DU 协议栈实现，新增能力足以支持电信研究人员、专网建设者和设备开发商开展实验。它并没有证明 Open RAN 互操作性的难题已经消失。

 因此，真正值得问的问题并不是 OCUDU 是否已经可以投入生产，而是：具备技术条件的团队现在能测试哪些部分？这些部分依赖什么硬件与时序假设？哪些功能仍需要独立的端到端验证？

 ## OCUDU 26.10 改变了什么

 项目官方的[发布说明](https://docs.ocudu.org/releases/release_notes/)列出了一组范围很广的新增内容。其中最受关注的是面向非地面网络（NTN）的 Release 17 支持。同一版本还加入了 Open Fronthaul 实现中的 O-RAN Split 7.2b 基线支持、8T8R 天线支持、面向 FR1 和 FR2 的 Release 15 与 16 波束管理、基于角度的定位、下行定位参考信号、两步随机接入、上行预调度、配置授权、TTI 绑定、PUCCH 重复发送以及 DTLS 支持。

 Linux Foundation 的[公告](https://www.linuxfoundation.org/press/ocudu-ecosystem-foundation-announces-ocudu-26.10-and-invites-developers-to-the-ocudu-ecosystem-developer-summit-october-20-22-near-washington-dc-to-learn-m-1791460743158)把这些变化归纳为三个实际方向：更多部署选择；更好的无线性能与更低延迟；以及额外的定位和安全功能。这个概括并不失真，不过详细发布说明比摘要更有价值，因为它暴露了各项功能分别处于什么成熟度。

 其中几项明确被标注为“基线支持”，或者尚未与 O-RU 完成测试。这不是无关紧要的脚注。在分布式 RAN 中，一个功能可以成功编译、通过单元测试，却在遇到特定无线单元、时钟源、压缩配置、传输网络或管理实现时失败。发布说明写明某项能力尚未经过端到端测试，实际上是在告诉评估者从哪里开始，而不是承诺工作已经完成。

 OCUDU 将自己描述为完整的开源 5G gNB 项目，覆盖中央单元控制面、中央单元用户面和分布式单元。其[官方文档](https://docs.ocudu.org/)称，项目面向商用部署和研究，支持通用 x86 与 ARM 硬件，遵循 3GPP 和 O-RAN 规范，并采用 BSD 3-Clause 许可证。代码仓库在 GitHub 上作为镜像提供，而贡献则在项目的[GitLab 仓库](https://gitlab.com/ocudu/ocudu)中进行。

 这一结构很关键，因为 OCUDU 并不只是协议演示程序。它的价值位于标准、实时系统、射频硬件和部署工具之间的边界。项目在公共代码中暴露的边界越多，需要检查、修改或验证 RAN 的人就越有可能真正理解它，而不是把 RAN 当成封闭设备来消费。

 ## 为什么 Release 17 NTN 最吸引注意

 非地面网络把 5G 流程扩展到卫星或其他空中平台参与的链路。无线链路不再是手机与附近基站之间短距离、相对稳定的地面路径。传播时延、时序、多普勒效应、卫星运动、覆盖几何关系和网关位置都会成为系统设计的一部分。软件必须在考虑这些条件的同时，避免假设卫星小区与普通城市宏小区行为相同。

 OCUDU 早先的材料已经记录了 GEO NTN 支持。26.10 版本把项目声明的范围扩展到 Release 17 NTN，教程则介绍了一种使用 SIB19 星历和时序支持的 NTN 模式，覆盖 GEO 与 LEO 场景。因此，对潜在测试者而言，[NTN 教程](https://docs.ocudu.org/tutorials/)比宣传标题更有用：它表明项目预期的测试环境需要合适的 UE 设备和经过严密控制的无线环境。

 这也是该版本不只对卫星爱好者有意义的原因。开放实现为研究人员提供了检查 NTN 假设如何流经配置、广播信息、时序与移动性逻辑的位置。使用供应商系统时，内部实现通常无法查看；而开放代码可以支持更难开展的实验。研究韧性连接、偏远工业站点、海上链路或地面与卫星混合网络的团队，也能把开放 CU/DU 当作架构比较的参照。

 但开源代码不会消除物理约束。开发者可以借助仿真或虚拟无线通路运行部分软件；若要进行现实的评估，则需要 UE、无线前端或仿真器、合适的时钟、5G 核心网，以及能够重现目标条件的传输路径。项目文档在部分 NTN 教程中列出了 Amarisoft 设备。这提醒我们，最有趣的演示仍可能依赖开放软件之外的专业设备或专有组件。

 还要注意另一层限制。支持一个标准功能，并不等于支持该标准覆盖的每一种卫星轨道、频谱安排、终端类别或移动模式。Release 17 NTN 是一个很大的技术领域。对 OCUDU 26.10 负责任的解读应是：它为 NTN 工作提供了公共实现表面，而不是已经把卫星 5G 这一产品类别解决了。

 ## 8T8R 与波束管理改变了什么

 对普通读者而言，8T8R 可能没有 NTN 显眼，但它或许与地面无线实验更直接相关。8T8R 配置使用八条发射和八条接收天线路径。更多天线端口可以加强对预编码和波束形状的控制，不过最终结果取决于无线单元、校准、信道条件、码本、处理能力，以及实际使用的空间层数。八个端口并不自动意味着八条独立数据流。

 项目关于该功能的公开合并请求说明，实现允许八个端口，但在所描述的阶段，每个码字的最大层数仍限制为四层。材料还特别提到了 CSI 配置、下行预编码、PDSCH 配置、HARQ 缓冲区大小和 PUCCH 负载处理。这些细节很有用，因为它们说明天线数量并不是一个单独的开关，而会触及调度器假设、反馈、缓冲区、控制信令和无线接口。

 OCUDU 26.10 还包括基线 Type-II 码本 CSI 报告与反馈，以及面向 FR1 和 FR2 的 Release 15 与 16 波束管理。波束管理是一组用于发现、测量、选择和维持合适波束的流程。在真实系统中，它涉及控制信令、参考信号、测量、移动性，以及分布式单元与无线单元之间的协调。代码路径能够支持这些流程是必要条件，但它是否有用，取决于完整链路能否在信道条件变化时正确工作。

 这也是应当把项目里程碑与发布说明放在一起阅读的原因。[v26.10 里程碑](https://gitlab.com/ocudu/ocudu/-/milestones/2)以更偏工程的方式记录了功能工作，包括 Cat-B 7.2 Open Fronthaul、Type-II CSI、8T8R、波束管理、基于角度的定位、下行定位参考信号、两步随机接入、上行调度、配置授权、TTI 绑定、PUCCH 重复发送、DTLS 和 Release 17 NTN。它还提供了问题与合并请求的可见轨迹，而不是把功能清单包装成已经完成的产品表面。

 对实验室来说，这是尝试该版本的充分理由。代码和问题历史可以帮助评估者判断故障属于哪个子系统。对网络运营商而言，这同样是一个提醒：集成计划必须写得具体。正确的测试不只是看小区能否启动，还要看目标 RU、时钟方案、信道带宽、数字学、UE 能力集合和业务流量配置在负载下能否保持稳定。

 ## Split 7.2b 有用，正因为它还没有变得无聊

 Open RAN 讨论经常把互操作性作为一种简写，指向这样的承诺：一家供应商的分布式单元可以与另一家供应商的无线单元协同工作。开放前传接口是这一承诺的核心。在 7.2x 功能切分中，部分物理层处理被分配到 O-DU 和 O-RU 之间，无线采样与控制信息通过前传网络传递。这可以扩大供应商生态，但也会让时序、数据包传输、压缩、同步和配置文件兼容性成为运营问题。

 [O-RAN Alliance](https://www.o-ran.org/specifications)发布面向开放、智能和可互操作无线接入网络的接口与功能规范。规范与可工作的多供应商集成之间存在明显区别。规范定义了契约；具体实现仍需就配置文件、可选功能、管理行为、同步、性能边界和测试覆盖达成一致。

 OCUDU 26.10 加入了 Split 7.2b 基线支持。官方发布说明特别指出，该功能尚未与 O-RU 进行测试。这一句话应该决定评估方式。对于需要检查或扩展接口的开发者，它很有价值；但它并不是假设任意 7.2b 无线单元都能成功连接的理由。

 7.2a 与 7.2b 的差异也会产生实际后果。预编码等功能的位置会影响 O-DU 和 O-RU 必须掌握哪些信息、多少信息需要穿过前传，以及无线单元如何参与波束成形。关于 7.2x 的公开技术材料通常会围绕预编码位置区分 A 类和 B 类。团队从 7.2a 配置迁移到 7.2b 时，不应预期只需修改配置文件，还必须验证支持的配置文件、压缩方式、控制面消息、时序和无线单元行为。

 项目现有文档也指向同一结论。OCUDU 当前公开的功能材料通过自有 Open Fronthaul 库列出 Split 7.2a，而 26.10 发布说明把 7.2b 描述为新增的基线能力。这一变化使 26.10 成为生态兼容性测试的有用对象，同时也意味着该版本应当使用明确列出的硬件和可复现的测试计划进行评估。

 合理的首次实验可以使用一个已知型号的 O-RU、固定频段与带宽、记录在案的时钟和同步配置，以及能够在不同构建版本间重复的流量测试。捕获前传数据包和控制消息，记录 CPU 负载、丢包、时序错误、接入稳定性和吞吐量。如果结果失败，目标应是定位哪个契约出了问题，而不是宣布整个架构可行或不可行。

 ## 定位是版本中隐藏的第二条主线

 OCUDU 26.10 增加了基于角度的定位和下行定位参考信号生成。这些能力指向一种不止提供连接的 RAN。无线测量可以支持位置估计、工业跟踪、资产监控、紧急服务和感知网络的应用。在卫星导航不可用或不可靠的环境中，定位对专网也可能有用。

 项目发布说明再次使用了谨慎措辞：定位功能被描述为基线支持，且尚未与 O-RU 完成端到端测试。这一限定对定位尤其重要，因为实现输出取决于天线几何、校准、同步、多径、测量质量，以及把无线观测转换成位置估计的算法。

 定位参考信号可以存在于协议栈中，却未必能在仓库、街道峡谷或工业厂房里产生有用的位置。评估者应把问题分开：网络能否配置并发送相关信号？UE 与无线单元能否稳定地测量这些信号？完整系统能否达到目标应用所需要的精度和可用性？OCUDU 26.10 似乎首先回答了第一个问题，并为第二和第三个问题打开了工作空间。

 这仍然很有意义。开放实现让研究人员能够检查时序和测量路径、比较算法并构建可重复的测试工具。它们也更容易帮助团队区分协议问题、无线校准问题和应用层定位假设。封闭系统可能提供更光滑的结果，却会让诊断变得困难。

 ## 安全工作不只是清单上的一项

 该版本包含用于安全通信的 DTLS 支持、改进的安全与韧性工作，文档中还提到 O-RAN 安全测试。Linux Foundation 公告同时提到持续模糊测试、参与 OSS-Fuzz 和独立验证。对于处理控制流量、用户流量及管理接口的网络协议栈而言，这些都是积极信号，因为它面对的攻击面很大。

 不过，安全支持应当被理解为流程与架构问题，而不是一枚徽章。DTLS 可以保护通信通道，却不会决定谁有权建立该通道、密钥如何配置与轮换、哪些端点值得信任、证书过期时会发生什么，或管理面、控制面和用户面流量如何隔离。模糊测试可以发现解析器和状态机缺陷的一些类别，却不能证明部署配置正确。

 在软件进入暴露网络前，应当把[安全与部署文档](https://docs.ocudu.org/tutorials/)与源代码及项目测试报告放在一起阅读。严肃的评估需要盘点每一条接口：核心网连接、F1 或内部 CU/DU 路径、CU 组件之间的 E1 连接、O-RAN 前传、管理 API、指标接口、容器接口以及任何远程命令路径。随后测试身份验证、证书失败、畸形消息、资源耗尽、权限隔离和日志记录。

 宽松的 BSD-3-Clause 许可证对商业和研究使用很有吸引力，但许可证不等于运营保障。仓库说明指出，部分代码可能实现 3GPP 规范，也可能存在额外的许可要求。计划交付产品的公司应进行自己的法律审查，追踪第三方组件并保留项目声明。同时应检查计划发布功能的具体代码与测试状态，而不是把顶层许可证当成完整的合规答案。

 ## 谁适合尝试 OCUDU 26.10

 最适合的对象，是已经能够构建并运行基于 Linux 的 5G 测试环境的团队。OCUDU 的[安装指南](https://docs.ocudu.org/user_manual/installation/)要求使用带实时内核支持的 Linux 操作系统。构建过程使用 CMake 和 C++17，依赖包括 SCTP、yaml-cpp、mbedTLS 和 FFT 库。指南列出 Ubuntu 22.04 或更高版本、Fedora 和 Arch 的安装路径，但实际实时性能仍取决于主机、CPU、网卡、内核配置和无线设置。

 研究 NTN、波束管理、定位或开放前传的团队，可以把该版本作为公开实验基础。专网团队可以研究 CU/DU 协议栈如何与 5G 核心网、O-RU 和管理系统配合。硬件开发商可以利用代码和问题历史验证接口假设。学习 5G 架构的学生和工程师同样能从中受益，但前提是把项目当作需要理解的系统，而不是装好后就忘记的二进制程序。

 项目教程覆盖的也不只是简单构建。教程包括使用 srsUE 和 Open5GS 的完整 split 8 网络、商用现货 UE 切换测试、NTN 配置、Near-RT RIC 集成、DPDK、硬件加速、容器镜像、Kubernetes 部署和性能调优。这种广度有助于把软件放回周边生态中理解，也揭示了现实评估的成本：部分教程需要 USRP、支持 DPDK 的网卡、加速器、时序设备、兼容的 O-RU 或商用 UE。

 如果团队要的是带供应商支持、经过认证的硬件组合、即装即用的管理面和合同约定性能目标的现成专用 5G 产品，OCUDU 就不是最省力的选择。它可能成为这类产品的一部分，但源代码开放并不会消除集成与验证负担。相反，能够修改代码还会带来额外责任：维护补丁集、跟踪上游变化、复现构建，并决定哪些测试结果足以满足部署的风险要求。

 ## 一套实际的评估方案

 先选择一个问题。一次测试 26.10 的所有功能，只会制造数量惊人的噪声。对卫星链路感兴趣的实验室，应从 NTN 教程和明确的时序、星历场景开始。评估无线单元互操作性的团队，应先选择一个 O-RU 和 Split 7.2b，而不是同时接入一批未经验证的设备。定位研究人员则应先确认信号生成和测量，再承诺应用层精度目标。

 固定具体的源代码版本，并记录编译器、内核、CPU、网卡、FPGA 或加速器、射频前端、UE、核心网和配置。将构建日志与配置文件和测试结果一起保存。开源电信系统对环境细节异常敏感；即使代码可见，一个无法复现的结果也很难解释。

 然后按层次拆分评估。第一步运行软件测试和静态检查。第二步使用最简单的受支持配置，建立稳定的接入与用户面会话。第三步加入目标功能。第四步再引入负载、移动性、时序变化或第二家供应商的组件。这样的顺序有助于区分基础系统问题、功能问题和多供应商问题。

 针对 Split 7.2b，同时捕获功能和运营指标。确认 O-DU 与 O-RU 对配置文件和压缩方式达成一致。在解释吞吐量之前先检查同步。测量数据包速率、延迟、抖动、丢包和 CPU 余量。在受控干扰下以及重启后重复测试。一个在干净实验台上成功一次的接口，还不能算是可互操作的部署。

 针对 NTN，应把时序和移动性假设与应用流量分开测试。观察时延和几何关系变化时预期行为与实际行为的差异。记录哪些部分是仿真、哪些部分是模拟、哪些部分经过真实射频或卫星设备。当有人随后把结果当作现场就绪的证据时，这一区分会非常重要。

 针对安全，应在开启远程访问前建立威胁模型。使用网络分段、最小权限、受保护凭据，以及在可用时经过签名或验证的制品。把容器镜像、辅助工具、管理端点和监控系统都视为可信计算基的一部分。可以审查项目安全报告和问题跟踪器，但不能把最终风险评估外包给上游维护者。

 ## 替代方案与比较参照

 OCUDU 并不是开展 5G RAN 实验的唯一开源路线。OpenAirInterface 仍是研究人员和运营商探索 Open RAN 与 5G 系统的重要参照项目。srsRAN Project 也提供开源 CU/DU 与无线接入协议栈，并拥有较丰富的文档与硬件集成材料。选择哪一个，应由要测试的功能和硬件组合决定，而不是依据一份笼统排名。

 有价值的比较通常很具体：哪个项目支持目标频段和切分方式？哪个项目对所选 O-RU 有经过测试的配置？哪个项目的调度器、PHY 实现或 E2 集成更符合实验？相关问题队列是否活跃？团队能否复现构建，并在出现硬件特定故障时获得帮助？与实验室里的确切设备相比，抽象的功能矩阵价值有限；真正有用的是一条已经被测试过的路径。

 OCUDU 的特点在于，它试图把范围较广的 CU/DU 实现、开放治理、10 月发布节奏，以及 NTN 和 8T8R 等较新的能力放在同一个公开项目中。即使团队不采用它，这也足以让项目值得关注。它的实现选择可以成为其他协议栈的比较点，公开的集成工作也能暴露标准留下解释空间的地方。

 测试开放协议栈的替代方案并不总是购买商用产品，也可能是更小、更受控的组件测试。团队可以在不搭建运营商规模网络的情况下，验证某个 Open Fronthaul 配置文件、定位信号路径或调度器改动。OCUDU 在这类场景中很有用，因为源代码、文档和问题历史让实验能够紧贴实现本身。

 ## 这次发布真正意味着什么

 OCUDU 26.10 的意义在于，它把开放 RAN 代码推向了更苛刻的阶段。第一次公开发布证明项目能够提供广泛的开放 CU/DU 基础；这次 10 月版本则提出了更难的问题：当基础设施加入卫星时序、更高阶天线配置、波束流程、定位、安全测试和更多前传配置文件时，能否保持透明的开发过程？

 这比宣称开源已经取代成熟电信基础设施更有价值。Open RAN 仍需通过互操作性测试、性能测量、安全审查、运营工具和长期维护来赢得信任。宽松许可证能让更多人检查和构建软件，却不会提供无线校准、频谱授权、同步、支持合同或生产验证。

 对开发者而言，眼下的建议是先选择一个 26.10 功能，在修改任何内容前复现项目记录的路径。对研究人员而言，该版本为 NTN、定位和解耦无线处理实验提供了更丰富的基础。对运营商和设备供应商而言，下一步应是使用明确列出的硬件进行互操作性测试并保存证据，而不是据此作出宽泛的采购结论。

 因此，OCUDU 26.10 已经值得测试，在多个领域也已经足以用于教学。它自己的发布说明同时清楚指出，哪些地方还不能在没有额外工作的情况下被信任。对新的基础设施版本来说，“相当可观的公共能力”与“清晰可见的限制”同时存在，正是开放源码观察者应当寻找的组合。

 ## 来源

 本文依据项目发布说明、官方文档、里程碑记录、公开合并请求、Linux Foundation 公告、O-RAN Alliance 规范资料、源代码镜像及相关教程整理。具体链接已保留在正文对应段落中。