构建天地一体6G测试平台：SDR、信道仿真器与开源5G软件栈实战指南-平芜编程栈

1. 项目概述：为什么我们需要一个“天地一体”的测试台？

如果你正在研究6G或者下一代无线通信，那么“集成地面与非地面网络”这个概念一定不会陌生。简单来说，它意味着未来的网络将不再局限于地面上的基站，而是会把卫星、无人机、高空平台这些“天上的”节点，和我们熟悉的蜂窝网络、Wi-Fi等“地上的”网络无缝融合在一起。想象一下，无论你是在远洋货轮上、深山老林里，还是乘坐高速飞行的航班，都能享受到稳定、高速的网络连接，这就是T/NTN（Terrestrial/Non-Terrestrial Networks）的终极愿景。

但理想很丰满，现实很骨感。把卫星链路和地面5G网络揉在一起，可不是简单的“1+1=2”。卫星动辄几百、几千公里的距离带来的巨大时延，高速运动产生的多普勒频移，以及复杂多变的大气传播环境，都会对现有的通信协议和算法提出严峻挑战。在论文里跑仿真是一回事，但真正的信号在真实的物理信道里会变成什么样？你的调度算法在时延高达几百毫秒的链路上还能不能工作？这些问题的答案，光靠软件模拟是给不出来的。

这就是为什么我们需要一个能“动手”的测试平台。它不能只是个黑盒子，而应该是一个允许我们从物理层射频信号开始，一直到核心网信令，都能进行干预、测量和验证的“白盒”环境。过去十年，我参与和搭建过不少无线通信测试床，深知从理论到实践这条路有多难走。硬件选型、软件集成、时钟同步、协议栈适配……每一个环节都可能成为拦路虎。本文的目的，就是为你梳理清楚构建这样一个面向T/NTN的测试平台，到底有哪些现成的“兵器”可用，以及如何把它们组合起来，形成一套可实操的解决方案。我们将从核心的硬件工具（如软件定义无线电和信道仿真器）聊起，再到开源的5G核心网和基站软件，最后探讨如何将它们集成，并分享一些关键的配置经验和避坑指南。

2. 核心硬件工具选型与实战解析

构建T/NTN测试床，硬件是基石。你需要能够生成和接收5G NR信号的射频前端，也需要能够模拟太空或高空恶劣信道环境的设备。这一部分，我们深入聊聊最核心的两类硬件：软件定义无线电和信道仿真器。

2.1 软件定义无线电：从通用硬件到专用协议

SDR的核心思想是把尽可能多的无线电功能（如调制解调、滤波、编解码）从专用的模拟电路转移到软件中，运行在通用处理器上。这带来了无与伦比的灵活性：同一套硬件，今天可以模拟5G基站，明天就能变成卫星信号接收机。

2.1.1 主流SDR设备横向对比与选型逻辑

市场上SDR产品众多，但用于严肃的通信系统研究，尤其是5G/NR相关，以下几款是经过广泛验证的“主力军”：

Ettus USRP系列：这几乎是学术界的标准配置。产品线从便携的Bus系列（如B205mini）到高性能的Networked和X系列（如N320/X310）应有尽有。选型时，关键看几个参数：
- 接口与带宽：USB 3.0接口的Bus系列适合单链路、带宽要求不高的原型验证（例如，初期算法开发）。而要跑满5G NR的100MHz带宽，或者进行MIMO实验，就必须选择配备万兆以太网或PCIe接口的X系列或Networked系列，以保证足够的IQ数据吞吐量。
- 同步能力：多设备协同工作（如Massive MIMO、分布式天线）必须解决时钟同步问题。许多USRP型号支持外部时钟/触发输入，而像X310这样的设备通常需要搭配OctoClock等多通道时钟分配器。一个极易踩坑的点是：如果你计划用多个USRP构建一个多天线gNB或UE，却没有使用同一时钟源进行同步，那么相位噪声和频率漂移会导致信道估计完全失效，实验数据将毫无意义。我的经验是，只要涉及多通道，预算里就必须包含同步方案的成本。
- 参考时钟：内置或外置的GPS驯服时钟（GPSDO）对于需要长时间稳定运行或与绝对时间对齐的实验至关重要。在模拟LEO卫星移动场景时，多普勒频移的精确模拟也依赖于高稳定度的本地振荡器。
Nuand bladeRF 2.0：这是一款性价比很高的产品，完全由USB总线供电，便携性极佳。它的优势在于开源硬件和活跃的社区。但在处理高带宽、高动态范围的5G NR信号时，其性能上限可能不如高端USRP。它更适合作为UE侧的射频前端，或者对成本敏感的教学演示平台。
LimeSDR系列：同样秉承开源精神，提供了不错的性能价格比。LimeSDR Mini 2.0等型号是许多创客和初学者的选择。但在企业级或要求严苛的研究项目中，其驱动成熟度、社区支持以及与主流开源5G软件栈（如OAI, srsRAN）的集成度，通常还是USRP更胜一筹。

实操心得：对于T/NTN研究，我强烈建议从USRP X310或N320起步。原因有三：第一，它们被OAI、srsRAN等主流开源项目原生支持，省去了大量移植和调试驱动的时间；第二，其足够的FPGA资源和高速接口能应对未来更复杂的物理层算法验证；第三，庞大的用户社区意味着你遇到的大部分问题，很可能已经有人解决并分享了方案。

2.1.2 SDR在T/NTN测试中的特殊配置

在天地一体化场景下使用SDR，有一些不同于传统地面测试的注意事项：

频率与增益规划：NTN使用的频段（如S波段、Ka波段）与地面5G（Sub-6GHz, mmWave）不同。你需要确保你的SDR设备（及其天线）支持目标频段。此外，卫星链路预算中路径损耗极大，需要仔细设置发射增益与接收增益。一个常见的错误是：为了获得更好的信噪比，盲目提高发射功率，导致信号放大器饱和产生非线性失真，或者接收端增益过高使ADC过载。正确的做法是结合链路预算计算，逐步调整，并用频谱仪监测信号质量。
定时提前量（TA）模拟：这是NTN仿真中最关键也最棘手的问题之一。地面网络中，TA用于补偿UE与基站之间的传播时延，范围很小。而在GEO卫星链路中，仅单程传播时延就高达120ms以上，这远超了标准5G协议中TA的调整范围。因此，在软件栈（如OAI）中必须启用并正确配置NTN扩展参数，如ta-Common-r17（用于补偿星地固定时延）和ta-CommonDrift-r17（用于补偿LEO卫星移动带来的时延变化）。这些参数需要根据你模拟的轨道高度和卫星类型精确计算并注入。

2.2 信道仿真器：在实验室里复现“太空环境”

信道仿真器是你的“时空魔法师”。它能对输入的射频信号施加精确控制的衰减、时延、多径和多普勒效应，从而在实验室里创造出从静止地面信道到高速运动的LEO卫星链路的任意环境。

2.2.1 商用信道仿真器：开箱即用的高保真方案

对于经费充足的实验室，Keysight PROPSIM F64、IZT C系列等商用信道仿真器是首选。它们提供图形化界面，可以轻松配置复杂的多径模型（如TDL、CDL）、动态多普勒谱，并支持极长的时延模拟（轻松应对GEO卫星的250ms+往返时延）。这些设备通常价格不菲，但提供了最高的保真度和可重复性。

2.2.2 基于SDR和FPGA的自建方案：高灵活性的替代路径

如果预算有限，或者需要高度定制化的信道模型（例如，模拟特定城市峡谷的卫星信道），基于SDR和FPGA的自建方案是可行的。

SDR方案：你可以使用两台SDR，一台作为发射机，另一台作为接收机，在��间用GNU Radio或自定义的软件程序实时处理IQ样本，施加时延、频偏和衰减。这种方案的灵活性最高，但挑战在于实时性。软件处理引入的延迟必须稳定且远小于你所要模拟的信道时延变化率，这对于模拟快速变化的LEO多普勒是一个巨大挑战。
FPGA方案：将信道模型实现在FPGA上（如使用Xilinx RFSoC平台），可以保证确定的、低延迟的处理性能。这是目前学术界构建高精度、可定制信道仿真器的主流方向。例如，你可以将3GPP TR 38.811中定义的NTN信道模型（包括卫星移动轨迹、大气衰减、闪烁等效应）用硬件描述语言实现，从而获得比通用商用设备更贴近特定研究需求的仿真能力。

注意事项：无论采用哪种方案，都必须对仿真器的性能进行校准。你需要用矢量网络分析仪测量其基础的频率响应、时延精度和动态范围。特别是在模拟非常小的多普勒频移（如GEO卫星的微小扰动）或极大的时延时，设备的底噪和时钟精度会直接影响实验结果的可信度。

2.3 商用终端：连接现实世界的桥梁

除了用SDR来模拟UE，使用真实的5G模组或手机（COTS UE）是测试端到端性能、验证协议栈兼容性的重要一环。Quectel、SIMCom等厂商的5G模组，配合可编程的SIM卡（如sysmocom的卡片），可以让你完全控制用户的鉴权信息，接入自建的5G核心网。

关键点在于3GPP版本：只有支持R17及以上版本的模组，才包含了为NTN设计的协议栈适配（如更长的定时器、扩展的TA命令）。在采购前，务必确认模组的3GPP协议版本。在测试中，这些COTS UE可以作为性能评估的“金标准”，对比你基于SDR实现的软件UE在吞吐量、时延和移动性上的差异。

3. 软件栈：构建5G网络的大脑与躯干

硬件提供了“躯体”，软件则是网络的“大脑”和“神经系统”。一个完整的T/NTN测试床需要实现从物理层到核心网的完整协议栈。

3.1 核心网软件：网络的控制中心

核心网负责会话管理、移动性管理、鉴权等控制面功能。在测试环境中，我们通常部署私有的5G核心网。

3.1.1 Open5GS：稳定易用的入门选择

Open5GS是一个用C语言实现的、功能全面的开源5GC。它的架构清晰，部署相对简单，特别是其提供的Web管理界面，可以方便地管理用户（UE）的签约数据。对于刚刚接触5G核心网的研究者来说，Open5GS的文档和社区支持比较友好，能让你快速搭建起一个可工作的网络环境。它支持基本的网络切片和VoNR，足以满足大多数T/NTN测试场景的需求。

3.1.2 OAI 5G Core：与RAN栈深度集成

如果你计划使用OAI的gNB和UE软件，那么搭配OAI 5G Core是一个自然的选择。它的优势在于同源集成，兼容性理论上最好。OAI 5G Core采用云原生设计，默认使用Docker容器化部署，这带来了很好的隔离性和可扩展性。不过，它的配置可能比Open5GS更复杂一些，对Kubernetes等容器编排技术有一定要求。

3.1.3 free5GC：Go语言带来的新思路

free5GC使用Go语言编写，在并发处理上有其优势。它同样遵循3GPP SBA架构。选择它可能更吸引那些希望利用Go语言生态进行二次开发或性能分析的团队。

部署建议：对于大多数实验性测试床，我推荐使用Open5GS。它的成熟度和易用性在前期能帮你避开很多坑。将核心网部署在一台独立的服务器上，并确保它与运行RAN软件的机器之间网络低延迟、高带宽。核心网的性能（特别是UPF的数据包转发能力）会直接影响到你测试的端到端吞吐量。

3.2 无线接入网软件：实现空口协议的关键

RAN软件是测试床中最复杂的部分，它实现了物理层、MAC层、RLC层、PDCP层等关键协议。

3.2.1 srsRAN：模块化与易用性的典范

srsRAN以其代码结构清晰、文档完善著称。它提供了完整的gNB、UE和核心网实现，并且各组件解耦良好。对于想要快速搭建一个基本5G链路，并专注于上层算法（如调度、资源分配）研究的人来说，srsRAN是上佳之选。它通过配置文件就能完成大部分参数设置，对新手友好。srsRAN官方也提供了对NTN特性的支持指南，可以配置卫星轨道参数和NTN特有的定时参数。

3.2.2 OpenAirInterface：深度与灵活的代价

OAI是功能最强大、也最复杂的开源5G协议栈实现。它提供了从物理层到核心网的完整参考实现，被许多顶尖研究机构和公司使用。OAI的优势在于其深度和可定制性——你可以深入到每一个函数去修改算法。例如，在NTN研究方面，已有不少工作基于OAI修改其RLC层协议以应对长时延，或者调整同步机制。

然而，OAI的编译、配置和调试难度也更高。它的代码库庞大，依赖复杂，经常需要针对特定的系统和内核版本进行适配。一个血泪教训是：务必严格按照官方wiki的指导，在推荐的操作系统版本（如Ubuntu 20.04）上从指定分支进行编译。随意升级系统或使用非推荐分支，极有可能陷入无尽的依赖库冲突和编译错误中。

3.2.3 软件栈与硬件的集成：驱动与同步

这是搭建测试床最关键的实操环节。无论是srsRAN还是OAI，它们与SDR硬件的交互都通过UHD驱动完成。

安装与测试UHD：首先，需要从Ettus官网下载并编译安装最新版的UHD驱动。安装成功后，运行uhd_find_devices命令，确保系统能识别到你的USRP设备。接着，运行uhd_usrp_probe命令，这会详细列出设备的所有信息，包括固件版本、子板型号、时钟源等。这一步是后续一切工作的基础，任何异常都必须在此阶段解决。
配置软件栈：以OAI为例，在编译gNB或UE时，需要通过CMake指定-DRF=1来启用射频前端支持。在运行时的配置文件中，你需要正确设置设备地址（如type=“x300”）、主时钟频率、采样率、发射/接收增益以及天线端口。
解决同步问题：
- 单设备内部：确保USRP使用稳定可靠的时钟源。如果设备有内置GPSDO，启用它。如果没有，至少使用外部10MHz参考时钟输入。
- 多设备之间：这是MIMO或分布式测试的难点。你需要使用OctoClock或类似设备，为多个USRP提供共享的10MHz参考时钟和1PPS（每秒脉冲）信号。在OAI的配置中，需要为每个射频单元指定相同的时钟源。我曾遇到过因为1PPS线缆长度不一致导致微妙级定时偏差，最终使得波束成形完全失效的问题。因此，线缆等长和接口紧固这些物理细节至关重要。

4. 构建端到端T/NTN测试平台：架构与集成

有了硬件和软件，现在我们需要把它们组装成具体的测试场景。下面以两种典型的架构为例，说明如何搭建。

4.1 场景一：透明转发卫星链路仿真（卫星作为“弯管”）

这是最简单的NTN集成场景。卫星只对信号进行放大、变频和转发，不进行基带处理。

4.1.1 硬件连接拓扑

[OAI UE Software] <---> [USRP A] <---> [信道仿真器 (模拟卫星链路)] <---> [USRP B] <---> [OAI gNB Software] (运行于PC1) (作为UE射频前端) (模拟传播时延、多普勒、衰减) (作��gNB射频前端) (运行于PC2) | V [Open5GS Core] (运行于PC3或服务器)

4.1.2 关键配置步骤与参数

信道仿真器设置：这是场景复现的核心。你需要根据模拟的卫星类型（GEO/LEO）设置参数。
- GEO卫星：主要设置一个大的固定时延（例如单向125ms）和极小的多普勒频偏（由于卫星相对地面静止，主要考虑地球自转和站址运动）。在Keysight PROPSIM中，你可以直接创建一个“Satellite”模型，输入轨道高度和倾角，软件会自动计算。
- LEO卫星：情况复杂得多。你需要设置一个时变时延（从最小仰角到最大仰角变化可达几十毫秒）和一个时变的多普勒频偏（可能高达几十kHz）。这通常需要信道仿真器支持动态场景脚本或导入星历文件。一个实用技巧是：可以先用STK或开源卫星工具箱生成卫星相对于地面站的时延-多普勒曲线，然后将其离散化为一系列时间片段，在信道仿真器中分段设置。
OAI gNB/UE配置：必须在配置文件中启用NTN模式并设置关键参数。
```
# 在 gNB 的配置文件中 (如 nr-gnb.conf) ntn_config = { ntn_mode = “enabled”; ta_common = 30720; # 举例：对应125ms时延补偿。计算方式：时延(秒)*载波间隔(Hz)。假设子载波间隔15kHz，125ms对应 0.125 * 15000 = 1875个采样周期。但OAI内部有特定换算，需参考其文档。 ta_common_drift = 10; # 对于LEO，设置一个漂移率 cell_specific_k_offset = 10; # 调度偏移，根据NTN场景调整 # 如果是再生卫星（gNB在星上），ta_common通常设为0 };
```
- 定时器调整：标准5G的定时器（如RRC、HARQ）是为地面微秒级时延设计的。在NTN中，必须大幅延长。例如，T310、N310等与无线链路失败相关的定时器需要增加。
- HARQ操作：对于GEO卫星，往返时延超过HARQ进程的持续时间，使基于快速反馈的HARQ失去意义。一种常见的做法是在配置中禁用HARQ，完全依靠RLC层的ARQ进行重传。这需要在MAC层配置中进行修改。
核心网配置：核心网通常无需为NTN做特殊修改，因为它处理的是gNB之后的逻辑。但要确保N2/N3接口的SCTP/UDP链路能够承受更大的端到端时延，避免因超时导致连接中断。

4.2 场景二：星上处理（再生式）gNB仿真

在这种更先进的架构中，卫星搭载了完整的gNB或gNB-DU。这带来了新的挑战：星地间的回传链路（Feeder Link）如何模拟？

4.2.1 硬件连接拓扑（简化版）

[OAI UE Software] <---> [USRP A] <---> [信道仿真器 (模拟用户链路)] (PC1) | (Service Link) | [OAI gNB Software (运行在“星上”PC2)] | V [网络仿真器/另一信道仿真器 (模拟回传链路)] | V [Open5GS Core (地面PC3)]

4.2.2 实现难点与解决方案

回传链路仿真：gNB与核心网之间的N2（控制面）和N3（用户面）接口需要穿越一个高时延、有损的卫星回传信道。这里有两种思路：
- 使用通用网络仿真器：在“星上”PC2和地面PC3之间，使用Linux tc(Traffic Control) 工具或更专业的netem来为IP流量添加固定时延、抖动和丢包。这可以模拟回传链路的网络层特性。但缺点是它无法模拟射频层面的损伤。
- 使用第二个信道仿真器：用另一套SDR+信道仿真器来模拟真实的射频回传链路。这保真度最高，但成本和复杂度也翻倍。你需要让gNB软件将其N2/N3流量通过某个网络接口映射到第二台SDR上发射出去。
星上处理单元：如果模拟的是完整的星上gNB，那么“星上”PC2需要运行完整的gNB软件，这对计算资源有一定要求。如果模拟的是CU-DU分离架构（DU在星上，CU在地面），那么你需要部署OAI或srsRAN的CU/DU分离版本，并确保F1接口能 over 仿真的回传链路。这涉及到更复杂的网络配置和协议栈参数调整。

避坑指南：在再生式场景中，最易出错的是IP地址和路由配置。gNB、核心网以及可能用到的网络仿真器都位于不同的网络命名空间或物理机器上。你必须仔细规划每个网卡的IP地址，并设置正确的路由规则，确保控制面信令（SCTP）和用户面数据（GTP-U）能够正确地在UE->gNB->核心网之间流转。建议先用ping和tcpdump工具逐段排查网络连通性，再启动复杂的协议栈。

5. 进阶工具与未来展望

5.1 远程可访问平台：没有硬件也能做实验

不是每个团队都有预算购买多台USRP和昂贵的信道仿真器。幸运的是，一些开放的远程实验平台提供了宝贵的资源。

Colosseum：这是一个规模庞大的无线网络仿真平台，提供了128个标准无线电节点（SRN），每个节点都连接着USRP X310和强大的服务器。你可以预约这些资源，在云端部署自己的协议栈容器，并通过一个大规模射频信道仿真器（MCHEM）将数百个节点连接起来，构建超大规模的虚拟网络。这对于研究超密集组网、频谱共享等需要大量节点的场景是无价之宝。它的学习曲线较陡，但一旦掌握，实验能力将得到质的飞跃。
POWDER/AERPAW：这些平台同样提供远程访问的真实无线硬件和计算资源。AERPAW的特色是集成了真实的无人机，可以让你在受控的室外环境中测试空地通信算法，这对于T/NTN研究尤其相关。

使用建议：这些平台是验证算法在接近真实射频环境中性能的绝佳场所。建议先在本地用小规模硬件完成基本功能验证和调试，再将成熟的代码容器化，部署到这些平台上进行大规模或包含真实移动性的测试。这能极大提高研究效率。

5.2 关键使能技术：O-RAN与智能超表面

未来的T/NTN网络必然是开放、智能和可重构的。

O-RAN集成：O-RAN将传统基站拆分为RU、DU、CU，并引入了RIC（无线智能控制器）。在T/NTN中，可以将RU部署在卫星或无人机上，而DU/CU部署在地面。通过开放的Fronthaul接口（如eCPRI）和RIC的智能控制，可以实现跨天地的协同波束管理、动态资源分配。你可以尝试将srsRAN或OAI作为O-RAN中的DU/CU软件，与商用或自研的RU进行集成，并通过开发xApp（运行在近实时RIC上的应用）来验证智能运维算法。
可重构智能表面：RIS是一种由大量低成本无源元件组成的平面，可以通过编程改变电磁波的反射特性。在NTN中，RIS可以部署在地面或空中，用于增强卫星信号的覆盖，特别是在城市峡谷或室内等信号遮挡严重的区域。目前，已有一些初创公司和研究机构提供RIS原型产品。在测试中，你可以将RIS作为一个可编程的“信道条件调节器”，研究其对链路预算和系统容量的提升效果。

5.3 常见问题排查与调试心得

搭建如此复杂的系统，遇到问题是常态。以下是一些快速定位问题的思路：

物理层无连接：
- 症状：UE无法同步到gNB的SSB（同步信号块）。
- 排查：
  - 频谱确认：首先用频谱仪或SDR的频谱扫描功能，确认gNB是否在正确的中心频率上发射了信号，且功率正常。
  - 同步参数：检查gNB和UE的频点、子载波间隔、循环前缀长度是否完全一致。
  - 时钟与同步：确认所有USRP使用同一时钟源，并用uhd_usrp_probe检查是否有严重的时钟锁相环告警。
  - 增益设置：逐步提高gNB发射增益和UE接收增益，同时用频谱仪监视，避免饱和。
RRC连接失败：
- 症状：UE能同步但无法完成随机接入（RACH）或RRC连接建立。
- 排查：
  - 核心网可达性：在gNB所在的机器上，ping核心网的IP地址，确保N2接口网络通畅。
  - SCTP关联：使用netstat -anp | grep sctp查看gNB是否与核心网的AMF建立了SCTP连接。
  - NTN参数：这是高频发区。反复核对ta_common、k_offset等NTN相关参数。对于GEO，ta_common必须设置正确；对于LEO，ta_common_drift也必须配置。
  - 日志级别：将OAI或srsRAN的日志级别调到DEBUG甚至INFO，仔细查看随机接入过程中的每一步反馈。日志通常会明确指出是“前导码未检测到”还是“定时提前命令无效”。
数据传输性能差：
- 症状：能建立连接，但吞吐量远低于理论值，或时延抖动大。
- 排查：
  - 信道仿真器设置：确认信道仿真器引入的附加噪声和衰减是否合理。过高的噪声底 floor 会直接限制信噪比。
  - 缓冲区设置：在OAI中，增大tx_sample_buff_sz和rx_sample_buff_sz可以防止因处理不及时导致的样本丢失。
  - 主机性能：使用top或htop监控运行gNB/UE软件的PC的CPU使用率。如果持续接近100%，说明主机已成为瓶颈，需要考虑性能优化或使用更强大的服务器。
  - 网络瓶颈：检查核心网UPF到外部数据网络（如互联网服务器）之间的路径是否存在带宽限制或拥塞。使用iperf3进行网络性能测试。

6. 从测试床到研究创新：挑战与机遇

构建一个可工作的T/NTN测试床本身就是一个巨大的成就，但这仅仅是开始。这个平台的价值在于支撑前沿研究。

6.1 当前的主要挑战

移动性管理：如何让UE在高速运动的LEO卫星波束间、以及在地面网络与NTN之间无缝切换？这需要修改现有的切换算法和测量报告机制，并在测试床上验证其性能。
星上处理与星间链路：再生式卫星和星间链路（ISL）是未来趋势。如何在资源受限的星载计算平台上高效运行部分或全部基站功能？如何模拟和测试激光或微波星间链路？这需要软硬件协同设计。
开放与智能：如何将O-RAN架构引入T/NTN？RIC（特别是近实时RIC）如何适应数百毫秒的传输延迟？开发能够跨天地域进行联合优化的xApp是一个充满机遇的方向。
全系统验证：目前的测试床大多针对单条链路或简单场景。如何构建一个包含多颗卫星、多个地面站、多种类型UE的规模化仿真验证环境？Colosseum这类平台提供了可能性，但如何将复杂的NTN信道模型和星历集成进去，仍需要大量工作。

6.2 给你的建议

从小处着手：不要一开始就追求构建最复杂的再生式LEO星座测试床。从一个透明的GEO卫星链路仿真开始，打通从UE到核心网的完整数据通路。先让最基本的ping和iperf跑起来。
文档与版本控制：详细记录每一步安装、配置和命令。所有对开源代码的修改，务必使用Git进行管理。复杂的测试床配置，可以考虑使用Docker Compose或Kubernetes Helm Chart进行容器化封装，确保环境可重现。
拥抱社区：OAI、srsRAN都有活跃的邮件列表和论坛。遇到问题时，先搜索历史记录，再清晰地描述你的问题、硬件配置、软件版本和日志片段。社区的力量是强大的。
跨学科思维：T/NTN的研究不仅仅是通信问题，还涉及航天轨道力学、嵌入式系统、云计算和人工智能。与相关领域的同事合作，能帮你更快地理解全貌并找到创新点。

构建集成天地网络的测试平台是一项系统工程，它混合了射频硬件、软件工程、网络协议和系统集成等多方面技能。这个过程充满挑战，但每当看到自己编写的算法在模拟的卫星链路上成功传输第一个数据包时，那种成就感也是无与伦比的。希望这篇综述和指南，能为你从理论迈向实践的征途，提供一张有价值的“地图”。