1. 为什么6G仿真不再是“换个参数”的事在无线通信这一行做了十几年从3G时代一路做到5G商用我一度觉得所谓“通信仿真”就那套东西搭一个链路级平台扔进去一堆信道模型和调制编码方案跑出BLER曲线再用系统级平台做调度和资源分配最后给出一堆吞吐量和时延的统计结果。做5G的时候这套流程还能转得动无非是把参数从LTE换成NR把带宽从20MHz调成100MHz或400MHz再加个波束管理模块。但当我开始认真接触6G预研项目后第一感觉是仿真工具这一层真的是要变天了。6G不是“5G Plus”不是把载波频率往后挪一挪、把子载波间隔调大一点就行。它有三个根本性的变化这三个变化直接把原来60GHz以下那套仿真假设的根基给掀了。1.1 三个被强行塞进仿真器的6G特征先说第一个太赫兹频段带来的信道建模革命。6G的目标频段会覆盖0.1THz到10THz这个区间这个区间里电磁波的传播行为和毫米波完全不同。大气分子吸收、雨衰、散射损耗变得极其显著而且有非常强的频率选择性。更重要的是太赫兹频段几乎没有非视距链路可谈穿透能力太差所以仿真里LoS的判断、波束对准的精度、反射路径的几何关系都成了决定性的因素。传统的统计信道模型比如3GPP的CDL模型在60GHz以下还能凑合用到了太赫兹尺度就得重新校准校准参数甚至要换建模思路。第二个特征是可重构智能表面。RIS本质上是一群可控的反射/折射单元它不是一个传统意义上的基站也不是终端很难用“一个节点加一根天线”的方式去建模。你要仿真RIS至少得给它定义每个单元的相位响应、入射角、反射角、能量损耗还要考虑它与基站波束训练的联动。老工具里根本没有这个实体类型硬塞的话只能用天线增益或额外路径损耗去模拟但那样算出来的系统增益极其理想化基本不可信。第三个特征是AI原生的空口设计。这个最要命。6G调制的很多研究方向比如AI辅助的信道估计、端到端学习的发射机结构、语义通信都要求仿真器和深度学习框架无缝联动梯度要能从损失函数一路传到信道模型或者预编码矩阵里去。传统离散事件仿真器压根没有“可微分”这个概念链路级仿真器能输出曲线但不能反向传播。你要做AI原生空口就必须找一个能跟TensorFlow或PyTorch融合的仿真工具或者自己搭一个。你要是把这三点都无视掉只是把5G工具的参数改了改跑出来的结果在项目评审时一拿出来就会被问穿你的RIS怎么建的你的太赫兹信道是哪个模型你的空口能不能跟AI训练打通这些问题一旦问出来方向就拐回工具选型了。1.2 从“蜂窝宏站”到“异构立体覆盖”网络模型范围变了还有一个让我很头疼的变化是网络拓扑。6G的愿景里明确包含空天地一体化即地面网、低轨卫星网、无人机网、海面网要协同组网。这意味着仿真场景里不光有基站和用户还要有低轨卫星星座轨道高度可能从500公里到36000公里不等卫星绕行周期从90分钟到24小时节点间的相对运动极其剧烈。多数经典网络仿真器是按照“地面宏站覆盖”这个假设来设计的。它们处理的是基站位置固定、用户移动节点的场景顶多加个小区切换。你让它去模拟LEO星座下星间激光链路和地面回传链路的动态拓扑它连轨道模型都没有更不用说什么星历数据、传播时延、多普勒频移了。我之前在某项目里试着在NS-3上模拟一个简化版LEO接入场景光是让卫星节点按轨道运动起来就折腾了很久最后还是在外部用轨道计算工具生成坐标表再写到运动模型里。这件事给我的教训是6G仿真平台必须具备“外部几何/轨道数据接入”的能力要么自己带空间模型要么留出标准接口跟STK这类工具打通否则网络级仿真的可信度会大打折扣。1.3 为什么“5G工具新参数”组合跑不出6G结果有人可能觉得我就先仿真6G中的某一个子问题行不行比如我只评估太赫兹频段的链路级性能那用5G链路仿真器换个信道参数不就行了吗我的经验是局部可以整体不行。链路级局部仿真可以用工具改参数来完成但6G的协议栈和RAN架构同样在变。比如6G空口可能在现有MAC调度之上加入AI控制器、新增语义通信的编解码层、核心网功能进一步下沉到边缘甚至终端侧。这些改动要求仿真器的模块结构足够像“积木”中层协议能轻松替换接口能自定义而不是在一个封闭的、设计好固定的分层结构里改配置。换句话说6G时代选仿真工具重点考虑的指标已经完全变了。不再是谁的用户界面好看谁的文档全而是三条硬杠杠第一扩展性和模型自定义能力强不强第二能不能和外部AI框架顺畅联动第三能不能支持跨域、跨空间尺度的混合场景。这三条直接决定你后面两三年的研究效率。2. 从链路到网络6G仿真的三层切分及各自工具选择很多刚接触6G仿真的朋友容易掉进一个误区一上来就想找一个“全能的6G仿真平台”希望它从物理层的波形到应用层的流量全都能搞定。我劝你尽早放弃这个想法。至少在当前阶段6G仿真必须分层来看。链路级、系统级、网络级这三层研究的问题完全不同工具的抽象程度也完全不同。硬要在同一个工具里做所有事要么性能太差跑不动要么每个层次都做得不够细最后两头不靠。2.1 链路级仿真评估物理层性能链路级仿真关注的是单个链路在给定信道条件下的性能表现。比如评估一种新的极化编码在太赫兹信道下的误码率评估某个波束赋形算法在强相位噪声下的表现或者比较不同子载波间隔配置下的吞吐量上限。这个层级最常用的工具还是MATLAB通信工具箱、IT这类计算型平台。它们的优势是算法库丰富、矩阵运算效率高可以精细建模调制映射、信道编码、OFDM参数、信道估计等各个方面。到6G阶段链路级仿真主要要解决的问题是太赫兹频段下大气吸收这个变量怎么建模、超大规模MIMO下硬件损伤相位噪声、非线性如何纳入、以及RIS的相位配置如何影响等效信道。我个人建议在链路级阶段不要盲目追求“全协议栈”而是要专注于把信道模型和收发机损伤做精。这一层的工具选型相对成熟但一定要确认你用的信道模型支持目标频段。像我以前在MATLAB里直接用了一套为28GHz设计的信道参数来做120GHz仿真结果算出来的容量高得离谱后来才发现频率相关参数没调整。这种错误很基础但确实很容易犯。2.2 系统级仿真评估调度和组网性能系统级仿真关心的是在一个多小区、多用户的网络环境中整体的频谱效率、用户吞吐率、资源调度的公平性等指标。它一般不精细建模每个比特的编解码过程而是用等效SINR映射到吞吐量曲线这样才可能在有限的计算资源内跑完上千个用户、数百个基站的场景。这一层的经典工具包括NS-3的NR模块比如5G-LENA、OMNeT配合Simu5G/INET以及MATLAB 5G Toolbox里的系统级仿真示例。到了6G阶段系统级仿真需要扩展的点包括RIS辅助的链路应该作为等效信道增益还是独立节点太赫兹波束的“窄波束动态对准”如何抽象为调度器能用的量高空平台或卫星节点接入的移动性管理算法怎么评估我的建议是在系统级仿真里尽量保留足够的L1/L2抽象但把资源分配和HARQ等机制做细。如果整条链路都做全“全双工双向”的比特级仿真计算量会大到无法接受。很多团队的实际做法是先用链路级仿真生成一个“SINR到BLER”的接口表然后在系统级仿真里直接查表或查曲线。这个方法非常实用也是我一直推荐的做法后面会展开讲。2.3 网络级仿真评估多域协同和端到端性能网络级仿真关注的层次更高包括核心网信令流程、移动性管理、内容缓存策略、切片编排、卫星回传链路对端到端时延的影响等。这类仿真的时间粒度是毫秒甚至秒级的空间范围可能是整个城市甚至全球星座。NS-3和OMNeT在网络级仿真中依然是主力。你可以在NS-3里搭建包括RAN、核心网甚至容器化微服务版本、互联网在内的端到端网络验证一个边缘计算任务从用户发出到云端响应的总时延。6G网络级仿真的新挑战是处理卫星节点的高动态性问题业务拓扑会随时间快速变化链路中断和重建频繁这要求仿真器支持按时间驱动的拓扑更新机制。我自己在做的某个6G天地一体化边缘计算项目里网络级仿真出现了“卫星走到某位置用户连接断开又切换”的循环场景NS-3里如果不设计好切换机制统计出来的时延曲线就是锯齿状一团乱麻完全无法分析。这种问题只能在网络级仿真里去暴露和解决。2.4 层间协同不要试图用一个仿真器解决所有问题综合上面三层我的核心观点是6G仿真应该是一条流水线而不是一个黑盒。链路级仿真给出物理层的行为模板系统级仿真复用这个模板评估调度算法网络级仿真再在更大的拓扑中评估跨域协作。比较有效的方法是“层次解耦外部接口”。比如说你想研究RIS辅助通信下的调度策略先在高保真的链路级仿真里针对RIS的若干配置方案分别测出不同的SINR-BLER曲线然后在系统级仿真里把RIS的反射行为抽象为“波束方向可调、增益由链路级表决定”的对象最后网络级仿真再关注RIS控制信令在网络里的传输开销。这样分摊下来每层仿真的计算量都可控结果也互相衔接。表格可以清晰表达各层级的目标、典型工具和关键风险仿真层级要回答的问题典型工具6G关键新增项链路级调制编码、波束算法在特定信道下的性能MATLAB、IT、自定义THz信道建模、硬件损伤、RIS等效信道系统级多用户调度、资源分配、干扰协调NS-3 5G-LENA、OMNeT、MATLAB sys-genRIS对象抽象、THz波束管理、卫星切换网络级核心网流程、端到端时延、星座组网NS-3、OMNeT、自研离散事件动态拓扑、天地一体化路由、多域协同3. 开源阵营全景NS-3、OMNeT、OpenAirInterface、Sionna的实战评估开源工具在通信仿真里一直占据重要位置到6G时代这种趋势只会更强。原因也很简单6G标准还在预研阶段闭源工具很难及时跟上变化开源社区千奇百怪的扩展模块反而能提供多样化的试错空间。下面这几个开源工具我都实际用过说一下真实感受。3.1 NS-3网络级仿真的稳定锚点但物理层模型别抱太大指望NS-3的定位一直很明确网络仿真而不是物理层仿真。它可以很细地模拟TCP/IP协议栈、路由算法、队列管理甚至能让真实的Linux网络栈跑在仿真环境里。在无线通信方向5G-LENA即5G NR模块提供了比较完整的RRC/RLC/MAC/PHY抽象支持载波聚合、波束管理、动态调度等典型功能。在6G项目中我主要把NS-3用作系统级和网络级的“大容器”。比如我会在NS-3里定义一个自定义的RIS节点类它不写具体的电磁反射方程而是暴露一个可配置的反射增益、相位噪声和波束方向参数。每当时隙调度开始时节点类根据这些参数返回一个等效信道质量供调度器使用。只要提前搭好这个抽象层NS-3在6G仿真里依然能打。不过NS-3有个不太友好的点模块复杂度高编译时间长。尤其是当你需要修改底层协议栈结构时C的继承关系和模板让刚上手的人很头疼一个链接错误查半天是常事。我现在一般用它的Python绑定来快速搭建顶层场景底层不变的东西保持C默认实现。3.2 OMNeT与Simu5G模块自由度更高但大规模场景吃力OMNeT本质上是一个离散事件仿真框架它的“模块门消息”模型让自定义协议变得非常灵活。配合INET库和Simu5G你可以从链路层一路搭到网络层模块间通信非常直观也很适合画架构图。如果要做协议栈的流程验证——比如6G核心网服务化架构里某个新信令流程——OMNeT的模块化建模能力比NS-3更顺手。但它的性能是大问题。OMNeT在事件处理上相对较重大规模多节点场景跑起来会明显变慢。我试过上万个节点的天地一体化场景OMNeT跑得有点吃力NS-3反而更抗造。所以我的经验是中小规模、想验证协议语义时用OMNeT大规模、要跑海量事件统计时用NS-3。3.3 OpenAirInterface从仿真到半实物的桥梁严格来说OpenAirInterface不完全是仿真器它是一套开源实现既可以在纯软件模式下运行也可以配合SDR硬件做实时外场实验。OAI提供了完整的4G/5G协议栈实现包括核心网OAI-CN和无线接入网OAI-RAN还有一个射频仿真模块可以把实际环境替换为模拟信道实现“半实物半仿真”。在6G项目里OAI的价值在于验证协议栈的“真实行为”。比如你想知道一个新的调度算法跑在实际协议栈里会不会产生冲突直接在OAI里改代码然后起仿真模式比在NS-3里重新实现一个高度抽象的MAC层要真实得多。代价是OAI的工程复杂度很高编译配置流程繁琐而且它的架构是绑定5G NR栈的6G的新空口协议进来还得做大量重构。我建议在研究初期别碰OAI等方案相对稳定、需要做验证的时候再引入。3.4 Sionna可微分链路仿真带来的革命性体验Sionna是NVIDIA开源的一个基于TensorFlow的链路级仿真库。它最大的特点是整个链路仿真过程是可微分的。这意味着你可以把信道模型、波束赋形、OFDM调制全部当作神经网络的计算图的一部分用梯度下降去做优化。举个例子如果你要做一个“端到端学习”的发射机让发射信号经过信道后在接收机端直接用神经网络解码这个目标函数要反向传播到发射机的参数上去。传统仿真器根本做不到这件事——它们只能正向计算不能反向传播。但在Sionna里你只要把发射机定义成一个带参数的神经网络把信道和接收机流程包在TensorFlow层里就可以用标准的训练流程去优化整个系统了。我最初用Sionna时还有点不习惯因为它跟传统以“事件”为驱动的仿真器完全不是一个思路更像是一个科学计算库。但当你真的开始做AI原生空口研究时可微分仿真几乎是必备能力。唯一要提醒的是Sionna的系统级调度能力很弱基本没有现成的多用户调度逻辑所以它更适合作为链路级数值实验平台配合其他网络仿真器完成整体验证。3.5 开源工具选型速查表研究任务推荐工具理由主要风险基于深度学习的空口优化Sionna可微分链路仿真支持端到端联合优化系统级能力弱需外部配合多小区调度算法评估NS-3 5G-LENA协议栈完整、规模大物理层保真度不够协议流程/信令语义验证OMNeT模块化自由度高大规模性能较差半实物协议栈验证OpenAirInterface接近真实协议栈可与SDR混搭工程复杂度高重构困难4. 商用工具与云平台特定环节依然不可或缺不要低估商用工具在6G仿真里的价值。虽然开源工具灵活但某些场景下商用平台的研究积累和前端可视化能力依然碾压开源。4.1 MATLAB 5G Toolbox链路级前端验证的首选MATLAB的优势不在“算法创新”而在“工程便利”。5G Toolbox里已经打包了大量的波形生成、信道建模、接收机算法示例你可以很轻松地基于它构建一个链路级基准平台。到了6G阶段MathWorks也已经在持续发布面向6G研究的更新比如对更大带宽、更高频段、RIS、无线传感等特性的支持。我用MATLAB做链路级验证时最看重的是它调试起来快。一个调制映射错误在Sionna里要看半天tensor形状在MATLAB里直接看Workspace里矩阵维度几秒钟就定位了。对于验证“某个DSP算法在THz信道下的性能”这类任务MATLAB依然是最理想的工具。不过MATLAB做系统级和大规模网络级仿真的能力一般所以我的定位是MATLAB做“前端探究”把关键波形和算法摸清楚然后立刻将可复用结论翻译成接口表代入到NS-3或自研平台中去。4.2 仪表厂商平台的定位精度高但灵活性受限Keysight、Rohde Schwarz、Spirent、VIAVI这些厂商都有自己的仿真与测试平台。比如Keysight的SystemVue和PathWave设计自动化软件可以结合其射频仪器做高精度的信道测量和波形生成Spirent在核心网和端到端信令仿真方面一直很强。这类平台最大的优势是与硬件测试环境无缝衔接。你在仿真里设计好的6G波形可以导出到仪表上生成真实射频信号再输入给被测设备。这种“仿真到测试打通”的能力是开源工具不具备的。但另一方面这类平台价格高昂而且其内部模型的更新通常滞后于研究前沿往往到了标准冻结后才有完整的支持。适合企业研究院、检测实验室使用对于高校里的预研验证来说性价比不高。4.3 云端仿真和流水线平台协作才是关键6G仿真还有一个常被忽略的维度平台化与人机协作。当你的项目团队有五个人同时在做不同层的仿真或者你需要跑大量随机试验时光靠个人电脑就不行了。我们需要把仿真跑在带GPU的服务器上通过容器化方式统一环境并用持续集成工具管理实验版本。我自己一般在实验室里维护一套轻量级仿真平台底层是Docker容器里面装好绑定的Python/C依赖和工具链中间是任务调度层用Shell脚本或简单的Makefile把仿真任务拆成批次再往上就是结果汇总层用Python把多轮实验的统计数据聚合成报表。这套东西不花哨但很实用。商业平台里也有像MATLAB Online、亚马逊或Azure云上部署的工具链但我觉得最适合科研阶段的还是自己在容器里维护一条轻量级流水线工具随时可以换不受供应商锁定。5. 一套我推荐的6G仿真管线搭建从信道模型到AI联合训练工具选型的最终目的是搭建一条能用的仿真管线。下面这套流程是我在多个6G预研项目中反复打磨出来的不敢说是最标准但对大部分“从算法到系统”的研究场景都适用。5.1 信道建模先确定频段再挑模型第一件事就是确定信道模型因为它是后面所有仿真结果的基础一旦出错所有结论都是废纸。如果是太赫兹频段的链路级仿真我会优先查找现有实测数据集比如NYUSIM发布的纽约地区毫米波/太赫兹测量参数或者用3GPP最新TR系列里为更高频段设立的模型框架。如果这些数据仍不够就得自建射线追踪环境。对于城市峡谷、室内等场景用QuaDRiGa或Wireless InSite这类基于几何的信道生成工具导出一组典型信道冲激响应然后作为固定输入喂给链路仿真器。这里有个非常重要的提醒信道模型的随机种子和架构参数必须记录到你的实验配置里并且固定下来。否则你换一台机器跑随机数不同曲线就差一截最后根本判断不了是算法改进导致的还是信道随机性导致的。我踩过无数次这种坑后来强制队伍里所有实验都要带版本化的配置文件才彻底止住“仿真结果不可复现”的问题。5.2 链路级数据如何转化为系统级接口链路级仿真跑出来的是一堆误码率、BLER曲线、吞吐量散点。这些数据怎么进入系统级仿真最经典的做法是查表法在系统级仿真器里每次要给用户分配资源时根据当前SINR从链路级生成的“SINR-BLER”表里查一个误块率再根据误块率概率性地判断这次传输是否成功。这个做法简单得令人发指但确实有效。做6G时唯一要扩展的是要把表格按多维度切片比如“对不同的RIS相位配置生成多张表”“对不同波束失准角生成细分表”。系统级忙时只需要拿着当前场景的多维索引去查表。更进一步的做法是用一个小型神经网络替代查表即把链路级仿真产生的大量“信道参数-调制编码-结果”数据作为训练集在系统级仿真器里离线加载这个模型每次根据当前参数前向计算一次得到性能估计。这其实就是AI辅助系统仿真的雏形我自己在项目里已经验证过精度可以逼近查表存储空间反而更小。5.3 在仿真环境里嵌入强化学习控制6G空口研究绕不开强化学习。无论你是在调度、波束管理还是能量控制里用RL本质都是把仿真器当作一个可交互的“环境”状态是由仿真器产生的观测动作是我们要学习的策略奖励是我们要优化的指标吞吐、时延、能量效率。我的实用建议是别在NS-3原生态里写RL训练循环太痛苦了。正确的做法是做一个环境包装器把NS-3或OMNeT的每次调度决策、每条链路状态、每个时间步的统计指标抽出来映射成Gym接口的observation、action和reward。外边再用Ray RLlib或Stable-Baselines3这类强化学习框架去训练算法通过进程间通信去调用仿真器。细节上要注意仿真器的运行速度可能比训练循环慢因此要多开几个并行仿真环境实例。每实例跑不同随机种子共同喂给同一个RL训练器。这样既能加速数据收集又能防止策略过拟合到单一随机序列。训练完成后还要回到一个固定种子的测试场景里重新评估否则你很难说清楚这个策略到底是“学会了控制”还是“背下了随机数”。5.4 时间尺度和数据处理的常见坑最后列几个我几乎每次都碰到的问题时间尺度不匹配链路级是微秒级的时间步系统级是毫秒级网络级是秒级。硬塞进同一个循环会导致事件累积、仿真速度陡降。解决思路是降采样传递链路级只输出统计值系统级只关心统计值而不是每个细微事件。数据量爆炸一次大规模仿真可能产生数GB的trace文件。不要直接用pcap或者全量trace做分析而是在仿真内部先做聚合汇总比如每小时输出一次平均时延、每小区输出一个资源利用率矩阵。数据要“榨干”之后再存。默认参数陷阱很多工具自带的默认参数都是按5G或4G校准的。直接套用6G场景会得到荒谬的数据。比如5G的默认子载波间隔是15kHz你仿真太赫兹大带宽场景时若不改成120kHz或更高系统容量直接被低估。每一层仿真前都要去复盘一遍接入、移动性、调度、信道、干扰这些模块用的到底是哪套参数。6. 我对6G仿真工具选型的最终建议前面把链路、系统、网络和AI这几层都拆开讲了一遍最后回到一个核心问题具体项目里到底怎么选我自己判断工具的底层逻辑是“看得准、改得动、跑得完”。看得准指在关键物理现象上不要做离谱的简化比如THz信道的分子吸收、RIS的外部控制接口、卫星的动态拓扑改得动指你拿到一个工具能在一周内把自定义算法模块加进去而不是要翻三个月源码才能动手跑得完指计算能力要能支撑你把实验矩阵全部跑完否则设计得再完善的仿真方案都是空谈。因此我的最终建议是不要追求单一全能的6G仿真平台把时间投入在搭建一条贯通链路、系统、网络的混合仿真流水线上。链路级选Sionna或MATLAB做精细物理层与AI融合系统级选NS-3或OMNeT做协议与调度网络级再叠加STK或自研轨道模块去处理天地一体化场景。每层之间用标准的接口数据文件对接而不是硬把整套东西塞进同一个进程。以我个人的经历而言刚开始觉得这样搞太碎片化、太麻烦总想找一个“开箱即用”的解决方案结果找遍市面上所有工具都没有能同时满足THz信道、RIS对象、AI可微分、卫星拓扑这四个条件的。后来放弃全能幻想、采用流水线架构后项目推进速度快了很多各层也都能用上最趁手的工具。6G仿真恰恰走到了这样一个阶段平台的边界由你自己划定工具的强项组合起来才是真正的“平台”。若你的团队还没有固定套路不妨现在就按这个思路先搭一个最小版管线信道数据入口、系统级调度器、结果统计出口跑通之后再往上叠加AI模块。等跑通了第一轮数据很多原本纠结的选型问题自然就都有了答案。