Noamwa开头一直在做通信协议仿真方向的工作，前段时间在搭建一套6G协议仿真环境时，遇到一个挺普遍的现象：团队拿到一批6G候选架构白皮书，照着拓扑图把节点、链路画出来，仿真模型搭了两周，最后提交结果时却说不清到底验证了什么。问题恰恰出在“网络架构设计”这一步——在6G协议仿真里，网络架构设计需要考虑的远不是一张图，而是一整套“假设-建模-参数化-验证”的闭环。这篇文章把我这些年做6G协议仿真时关于网络架构设计的心得做一个系统性梳理，讲清楚每个决策背后的逻辑、可落地的配置方法，以及我踩过的坑。适合正在做6G预研、协议仿真、网络架构评估的工程师，也适合刚进入通信仿真领域的同学参考。
1. 6G仿真中的网络架构设计，为什么不是“照着拓扑图画节点”
1.1 5G的架构模板在6G预研中并不好用
5G网络架构经过多年标准化，已经形成相当稳定的框架：NR接入网加上基于服务化架构（SBA）的5G Core，仿真时按gNB、UPF、AMF、SMF等网元去建模，基本都能找到现成参考。这也是很多人做通信协议仿真的惯性思路——找一个成熟的架构模板，替换参数，跑起来，出结果。
但到6G阶段，这个路径走不通。6G目前处于标准前探索期，3GPP、ITU以及各国研究组织提出的候选架构差异非常大。有的强调空天地一体化，把卫星、高空平台、无人机都纳入统一的接入体系；有的强调通感算智融合，在通信节点上同时叠加感知、计算和AI推理能力；也有的直接把核心网功能打散下沉到边缘，让用户面甚至控制面可以在靠近终端的位置完成闭环。
这意味着什么？意味着网络架构在6G协议仿真里不是“待配置的模板”，而是“待验证的假设”。你不能在一开始就认定某个架构一定是对的，然后用仿真去“证明”它。仿真设计者的角色从“搭积木”变成了“设计积木本身”——你要决定有哪些网络功能、功能之间如何交互、信令走什么路径、数据面如何转发。这恰恰是6G协议仿真中最有价值的部分，也是最难的部分。
另一个现实问题是：5G仿真有成熟的协议栈模块可以直接复用，比如NS-3里有5G-LENA、OpenAirInterface等。6G没有统一协议栈，很多模块需要自己定义。架构设计一旦定错了方向，后续所有协议流程、接口消息、参数配置都会跟着错，返工成本极高。
1.2 先定抽象层级，再谈架构建模
我在接触过不少项目后总结出一个经验：6G协议仿真中网络架构设计的第一件事，不是打开仿真器，而是先确定“我要验证什么”，然后按验证目标决定架构抽象层级。
如果你要验证的是物理层波形、调制编码方案、信道估计性能，那网络架构基本不需要建模太细，信道模型、节点位置、发射功率这些就够了。如果你要验证的是协议交互，比如切换信令流程、服务化接口的消息交互、控制面与用户面的分离机制，那就需要建模网络功能、接口消息、状态机。如果你要验证的是端到端业务质量，比如时延、可靠性、算力调度的协同，那就要建模流量模型、队列、转发策略，以及多节点间的资源竞争关系。
对应到仿真粒度，大致可以分三个层级：
- 链路级仿真：聚焦物理层，网络架构上只需关注节点坐标、信道参数、收发机配置。
- 协议级仿真：建模网络功能节点、接口消息、状态机，网络架构是主体。
- 系统级仿真：多节点拓扑、流量模型、资源管理、移动性管理全都要有，网络架构是骨架。
不同层级对网络架构设计的详略要求完全不同。我见过最典型的低效案例，就是有人明明只想验证一个切换算法，却把整个核心网的服务化架构全部建模了，结果仿真脚本跑了几个星期，一大半时间都耗在与研究目标无关的细节上。过度建模是6G协议仿真中最大的时间杀手。
我建议在项目启动时就把抽象层级写进配置文档里，每个参与仿真的人都要清楚：当前这个阶段我们关注什么、不关注什么、哪些模块可以简化。后续每一步架构设计决策都要问一句“这个细节对我的验证目标有影响吗”。没有影响的部分，能简则简。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。