6G协议仿真网络架构设计：功能视图、拓扑映射与时延预算

开头一直在做通信协议仿真方向的工作，前段时间在搭建一套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协议仿真中最大的时间杀手。

我建议在项目启动时就把抽象层级写进配置文档里，每个参与仿真的人都要清楚：当前这个阶段我们关注什么、不关注什么、哪些模块可以简化。后续每一步架构设计决策都要问一句“这个细节对我的验证目标有影响吗”。没有影响的部分，能简则简。

2. 三视图拆解架构：功能、拓扑与部署映射

2.1 功能视图：把通信、感知、算力功能全列出来

6G网络功能相比5G多了一个维度：不仅仅是通信功能，还有感知功能、计算功能、智能功能。做仿真架构设计的第一步，是把功能清单列全，搞清楚每个功能是集中式还是分布式、部署在哪一层、与其他功能有什么依赖关系。

举个例子，“通感一体化”是6G的重要方向。基站既要发通信信号，又要做感知测量，那在仿真功能视图里，同一个物理节点就要建模两个功能模块，而且这两个模块共享资源状态——频谱、功率、时隙。如果你在仿真里把感知功能当作一个独立节点，资源冲突和调度耦合关系就完全体现不出来，仿真结果等于白做。

我自己的做法是画一张功能清单表，每行一个功能，列字段包括：功能名称、所属域（接入/承载/核心/计算）、部署形态（集中式/分布式）、依赖的其他功能、关键性能参数。这张表不写代码，就是一张文档，但它决定了后续所有仿真模块的边界。功能视图做不清晰，后面拓扑视图和部署视图都会乱。

2.2 拓扑视图：三维节点与逻辑物理链路分离

拓扑视图解决“节点放哪里、链路怎么连”的问题。6G空间维度明显扩展，节点类型多了低轨卫星、高空平台、无人机、地面微站，链路状态也差异巨大——卫星链路的传播时延可能高达几十毫秒，地面光纤时延不到1毫秒。仿真建模时如果沿用5G陆地网络均匀部署的做法，链路时延、断链概率、移动性差异就全部失真。

这里要特别提醒一个容易被忽视的问题：逻辑拓扑和物理拓扑的分离。6G核心网功能下沉、边缘智能、服务化架构之后，逻辑上的业务链路可能跨越多个物理节点，但物理拓扑上只是简单的星型或网状连接。比如一个控制信令逻辑上从终端经过“接入节点-边缘控制器-中心编排器”，物理上可能经过三次无线跳转和两次光纤传输。建议在仿真中分别维护两张邻接表，一张是物理链路表，用于信道模型和传播时延计算；一张是逻辑业务链路表，用于路由决策和服务编排计算。这两张表混在一起，很容易导致时延估算错误。

节点坐标方面，6G仿真必须是三维的，不能只给经纬度。卫星和无人机有高度变化，移动模型也在三维空间运动。NS-3等工具虽然默认支持三维坐标，但很多人在写脚本时还是习惯只配x、y，忘了z轴。这个问题在纯地面网络仿真中无所谓，一旦加入非地面节点，z轴的缺失会让高度相关的信道模型和链路预算完全失效。

2.3 部署视图：功能到节点的映射关系

部署视图解决“哪些功能部署在哪个物理节点上”。同样的功能视图和拓扑视图，可以有不同的部署方案，这是6G架构研究中非常核心的议题——集中式部署和分布式部署的对比、云边端协同部署的权衡等。在仿真中，这个映射关系要建模成可配置的映射表：功能ID映射到节点ID，再映射到资源池ID。

我强烈建议把部署映射关系放在独立的配置文件里管理，不要写死在代码中。原因很简单：6G架构研究很大一部分工作就是做部署方案对比。同一个功能视图，三个不同的部署方案，只需要改配置文件就能跑对比实验，代码完全不用动。这么做不仅效率高，还能避免改代码引入不必要的bug。

实际做的时候，功能到节点的映射关系不是简单的“一对一”。有些功能可以共享部署在同一节点上，有些功能又需要冗余部署在多个节点上保证可靠性。这些在配置里都要表达清楚。我习惯用类似JSON的格式来描述部署关系，虽然仿真器不一定能直接读取，但至少我们要用结构化方式管理它的版本演进。后面仿真脚本生成节点配置时，就可以基于这张映射表自动展开,避免人工维护不一致。

3. 把架构决策落到仿真参数：以NS-3为例的配置思路

3.1 节点与移动模型：从二维静态到三维动态

NS-3里的节点建模是所有配置的基础。6G架构设计落到NS-3上，第一步就是定义节点数量、类型、坐标和移动模型。由于6G涉及空天地一体化，节点配置通常要分几个层次：地面节点、空中节点、轨道节点。

我常用的一套配置逻辑是：

• 地面基站节点：固定坐标，站间距根据覆盖需求设定。
• 终端节点：分簇部署，簇内低移动性，簇间偶发迁移。
• 无人机节点：固定航线巡航，高度通常300米到1000米，速度相对较慢。
• 卫星节点：沿轨道运动，高度在1000公里到36000公里之间。

移动模型的选择直接影响仿真复杂度。低轨卫星如果每个仿真步长都重新计算位置，计算量会非常大。我建议先用简化的轨道参数方程生成离散位置序列，再按照固定时间间隔更新节点位置，而不是逐帧驱动。这样做在系统级仿真中足够精确，又能把计算开销控制在合理范围。

要注意的是，节点模型不等于网络架构。节点配置只是物理实体层的建模，你还需要在节点上挂载网络功能模块、协议栈、队列等，才能形成完整的架构仿真环境。

3.2 信道模型在架构级仿真中的精度选择

很多做协议级或系统级仿真的人，对信道模型的态度容易走极端。一种是什么都往精细了配，把每个链路的衰落系数、多径参数全部设置上，结果仿真速度惨不忍睹；另一种是统统用最简单的理想信道，完全忽略不同链路间的差异性。

这两种做法在6G架构仿真中都不合适。架构级仿真不需要像链路级仿真那样精确到每个衰落系数，但必须正确反映链路间的本质差异。我通常的做法是：

• 地面链路：使用标准路径损耗模型，比如3GPP UMa或UMi，加上合适的阴影衰落参数。
• 卫星链路：使用自由空间路径损耗模型，同时考虑仰角变化对损耗的影响。
• 无人机链路：在地面链路模型基础上，增加动态遮挡因子。

信道模型的选择一定要记录在仿真配置里。很多人跑完仿真写报告时，说不清信道模型到底用的什么版本、什么参数，评审一追问就露馅。6G架构评估时，信道模型是否合理往往是第一个被问的问题，提前把模型参数记录下来能省掉大量沟通成本。

3.3 时延预算表：端到端指标拆解的实操方法

网络架构设计的最终价值，要落到时延预算这类量化指标上。6G提出的低时延场景，端到端时延需求比5G更苛刻，这个预算必须拆分到架构的每一段，才能指导仿真参数设置。

我沿用多年的做法是：

1. 先定端到端时延需求。比如某个确定性网络场景要求端到端时延不超过2毫秒。
2. 按架构划分时延段。接入段、承载段、核心网段、应用计算段各分配多少预算。
3. 每段预算再细化到节点处理时延、排队时延、传播时延、传输时延。
4. 把这些数字填到仿真脚本参数里。

举个例子，端到端时延预算2毫秒，可以这样拆：接入段0.5毫秒、承载段0.8毫秒、核心网段0.5毫秒、计算段0.2毫秒。在仿真脚本里，无线链路的传播/排队参数按接入段预算设置，承载网每跳的处理时延按承载段预算分摊，核心网网元的处理时延按核心网段设置。

时延预算表还有一个好处：仿真跑完后，把实测每段时延和预算表对比，可以快速定位瓶颈段落在哪里。这是架构评估中最直观、最有力的分析手段。

4. 空天地一体化拓扑建模：动态链路与切换的仿真取舍

4.1 非地面节点的移动性建模：先简化，再细化

空天地一体化是6G网络架构中最显著的变化之一。低轨卫星、无人机、高空平台等非地面节点的引入，给仿真带来了地面网络完全没有的挑战：拓扑动态变化。

低轨卫星绕地球一圈大约90分钟，对地面某个固定点的可见时间窗口通常只有几分钟到十几分钟。这意味着节点间的链路关系不是静态的，而是周期性变化的。仿真中怎么处理这种动态性？我见过两种常见做法：

一种是固定时间窗口法。把仿真时间切分成窗口，每个窗口内的拓扑视为静态，窗口边界处重新计算可见性并重建邻接关系。优点是实现简单、计算量低，适合架构级仿真；缺点是窗口边界的瞬态行为可能不真实。

另一种是动态更新法。每个仿真步长都更新卫星位置，计算节点间可见性，动态调整链路状态。优点是精度高，但计算开销极大，尤其是卫星数量多、仿真时长较长时，跑一轮仿真可能要几天。

从实操角度，我建议在架构验证初期先用固定时间窗口法，先把控制面流程、数据面转发逻辑跑通，验证架构方案本身的可行性。等确定核心架构合理之后，再逐步细化移动性建模，增加动态更新逻辑，评估动态拓扑对性能和稳定性的影响。不要一上来就搞全动态，耗时巨大还不一定能得出更有效的结论。

4.2 切换流程建模：控制面最核心的部分不能省

空天地一体化意味着终端需要在不同接入节点间频繁切换：地面基站到卫星、卫星到卫星、基站到无人机等。切换建模在架构仿真中属于控制面核心流程，绝对不能省略。

切换仿真的关键不在于物理层信号测量怎么做，而在于高层信令流程的建模。我建议至少建模这几个阶段的状态机：

• 测量上报：终端周期性测量邻区/邻节点信号质量，上报给服务节点。
• 切换决策：服务节点或网络控制器根据测量报告和目标节点负载情况做出切换决策。
• 上下文转移：终端上下文从源节点迁移到目标节点。
• 路径更新：数据面转发路径从源节点切换到目标节点。
• 切换完成：目标节点确认终端接入成功，源节点释放资源。

这五个阶段在架构仿真里都要有对应的模块和消息定义。很多6G架构研究论文中提出的创新切换策略，比如“按需切换”“预测性切换”“多连接协同切换”，本质上都是在这套状态机上做调整。如果仿真环境里没有把基础切换流程建模好，这些新策略根本没有验证的载体。

4.3 一个可落地的仿真场景参数配置表

下面给一个我在空天地一体化架构仿真中常用的参数配置示例，供读者根据自己场景调整：

这个表只是示意，不同研究目标下参数差异很大。但有一个原则是通用的：参数配置表本身应该成为项目文档的一部分，每个参数都要有说明和依据，方便后续复现和复盘。

5. 跨域协同与动态编排：网络切片和算力融合的仿真设计

5.1 网络切片用“叠加拓扑”思路建模

6G网络切片和5G相比有一个明显的升级：不再是单纯的资源隔离，而是多域协同的端到端切片。一个切片可能同时贯穿接入网、承载网、核心网和算力资源域。这在仿真架构里怎么表达？

我建议用“叠加网络”的思路：在同一份物理拓扑上叠加多个虚拟拓扑，每个虚拟拓扑对应一个切片实例。切片内维护独立的路由表、资源池配置和服务质量等级，但底层共享物理链路和节点资源。

具体到NS-3这类离散事件仿真工具，可以通过自定义的拓扑数据结构来实现。底层是一张物理链路表，记录真实的节点连接和链路容量；上层是多个虚拟路由表，每个切片一个，虚拟路由表决定切片内业务的转发路径。当一个数据包到达节点时，先根据其所属切片的虚拟路由表查询下一跳，再映射到底层物理链路上发送。

这种设计的最大好处是：切片的数量、带宽配额、服务质量策略都可以通过配置修改，不需要改动核心仿真代码。比较适合做“不同切片策略对整体网络性能影响”这类研究。

5.2 通信-计算-智能融合的跨域仿真方法

6G网络架构设计中的一个新变量是计算资源和AI能力也成为网络资源的一部分。基站不再是只做通信转发，还要承担边缘推理、任务卸载、模型协同计算等功能。这部分在传统通信仿真工具里没有现成模块，需要自己扩展。

我的做法是给每个节点增加计算资源属性，包括CPU核数、计算能力（MIPS）、内存大小。再定义一个任务生成模型，周期性生成计算任务，每个任务有数据量、计算需求、截止时间等属性。仿真中执行任务调度和卸载算法时，综合考虑通信链路时延和节点计算时延，决定任务在哪里执行。

跨域仿真需要特别注意的是资源竞争的耦合关系。通信和计算不是独立的——通信任务占用频谱资源，计算任务占用CPU资源，但如果节点既要转发数据又要执行推理，通信队列和计算队列会互相影响。在6G通感算智融合场景下，这种耦合关系恰恰是架构设计要研究的重点，不能在仿真里回避掉。

5.3 数字孪生模块的仿真表示与开销统计

数字孪生网络是6G的一个热门方向。它的思路是在数字空间建立一个物理网络的虚拟镜像，持续同步状态，支持预测、仿真和决策优化。网络架构仿真中如果要包含数字孪生模块，需要额外建模状态同步的开销。

我见过不少人在架构仿真里假设数字孪生是“免费的”，即同步数据不影响网络性能。这种假设在概念验证阶段可以接受，但进入性能评估阶段就会产生误导——状态同步本身要消耗带宽和计算资源，尤其在节点数量大、同步频率高的场景下，这部分开销非常可观。

建议在仿真中单独建模一个孪生数据平面，负责节点状态采集、上报、同步和下发。同步周期、数据包大小、上报范围都做成可配置参数。这样在评估架构方案时，能够把数字孪生引入的额外开销量化出来，对比“带孪生”和“不带孪生”两种模式下的性能差异。

6. 架构验证的指标设计与结果复盘

6.1 端到端时延的分位数统计比平均值更关键

6G架构验证中最容易踩的坑之一，就是只看平均时延。空天地一体化场景下，卫星链路偶尔被遮挡导致的瞬时时延飙升，对平均值贡献不大，但对高可靠低时延场景影响非常致命。平均时延是5毫秒，不代表99.9%的业务都能满足2毫秒的时延要求。

我建议统计端到端时延时至少输出四个值：P50、P95、P99和最大值。同时按业务类型分别统计，因为不同业务对时延的敏感度完全不同。比如增强移动宽带业务可以容忍较大的尾部时延，但工业控制类业务对P99甚至P99.9有严格要求。架构设计能不能满足需求，重点看尾部指标，而不是平均值。

6.2 控制面开销的统计口径要在建模前定好

控制面开销是评估网络架构设计是否高效的关键指标之一，但统计口径很容易出问题。需要提前明确：统计是否包括接入网的测量上报？是否包括核心网网元之间的接口信令？是否包括卫星节点的星历更新和波束切换信令？

同一个架构方案，不同统计口径下的控制面开销可能相差一个数量级。我建议在仿真配置文件中定义好“控制面开销统计范围”，比如明确“统计从终端发起的全部控制信令，包括接入网测量上报、切换信令、核心网服务化接口信令，不包括链路层的调度请求”。这样所有实验结果才有可比性，写报告时也不会被质疑数据的口径问题。

6.3 仿真时间与精度的平衡：分层细化策略

6G架构仿真面临的现实困境是：节点多、功能多、动态性强，仿真速度非常慢。我见过最极端的案例，一个包含50个基站、200个终端、10颗卫星和完整核心网协议的仿真场景，一台服务器跑一周只跑完几秒钟仿真时间。这种效率没法做参数扫描，更没法支撑架构迭代。

我的经验是“分层细化”策略：

1. 先用最小规模拓扑跑通流程，比如2个基站、10个终端，验证协议流程和代码逻辑正确。
2. 逐步增加节点数量，优先增加对研究目标影响最大的部分。
3. 对非关键域的细节尽量简化，比如在研究接入网架构时，核心网部分可以使用简化的时延模型代替完整信令流程。
4. 每个阶段跑完后，先分析结果，确认数据和预期一致，再继续扩大规模。

仿真速度和精度之间没有绝对的最优解，只有与当前研究阶段匹配的平衡点。关键是不要试图一次性把整张6G网络都精确建模，那样做通常意味着项目进度失控。

作为一个长期做通信协议仿真的人，我最后的体会是：6G仿真中的网络架构设计，本质上是一门“抽象与取舍”的学问。架构图谁都能画，但能在正确的位置做简化、在关键的位置保留细节，才是仿真方案是否可靠的分水岭。每次跑仿真之前，把架构假设清单写清楚，每个模块简化了哪些、保留了哪些，原因是什么。这些记录会在后续评审和复现时体现出巨大价值。我踩过不少坑，也走过不少弯路，如果这篇文章能帮你少走一段，那这些经验就没白写。