6G网络架构白皮书拆解:从愿景到可验证的架构设计

发布时间:2026/10/1 9:34:30
6G网络架构白皮书拆解:从愿景到可验证的架构设计
简介《6G网络架构展望白皮书》是2023年中国电信研究院与中兴通讯联合发布的6G架构研究文件面向通信行业研究人员、网络工程师及关注6G演进的从业者系统阐述6G网络的设计理念与体系框架。资源为PDF格式共1个文件压缩包大小2.65MB内容涵盖6G设计思路、总体架构、新架构思考、核心特征、新业务场景及未来展望六大章节重点介绍了NCU、NPU、NDU、NIU等网络单元及架构极简、智能内生、分布自治等关键特征。目前已有349人学习适合作为6G网络架构研究与技术预研的参考资料。通过阅读可获得对6G核心设计原则和逻辑功能的全景式认知并了解沉浸式XR、元宇宙、空天地一体、自治专网等典型业务对网络的差异化需求为后续标准跟踪与方案设计提供基础支撑。1. “6G网络架构”不是一份能直接抄的文档先弄清楚它到底在讲什么“6G网络架构”白皮书圈外看是愿景圈内看是需求文档。但多数人读完的真实感受是指标很震撼却不知道该先动哪里。移动通信每一代网络的重写幅度都远大于数值提升——4G把电路域消掉了5G把核心网服务化了而6G要动的是整个接入网络的存在形态接入不一定是基站控制不一定是信令转发不一定是网络节点。这篇文章把白皮书里的展望拆成可辨别的架构变量落到选型和验证路径适合通信工程师、网络规划人员、高校做课题的团队。读完后你能回答一个问题这个架构方向值不值得我投入。2. 6G网络架构到底改了哪几层四个关键变化与两个边界2.1 全服务化核心网服务化向接入网延伸5G核心网已经把网络功能拆成了独立服务AMF、SMF、UPF各自以服务化接口对外提供能力网元之间不再是一根根硬管道。但无线接入网还是相对封闭的gNB内部功能模块没有真正按服务粒度拆开。6G白皮书的架构展望里最常被提到的方向就是“全服务化网络”接入网侧的功能也被拆成可编排、可组合的服务单元比如调度服务、移动性管理服务、测量服务。这个变化意味着设备形态会变。过去接入网是“一台基站搞定调度、切换、资源管理”未来可能是一套分布式软件栈跑在通用硬件上无线资源管理RRC、用户面PDCP等协议功能按需组合。规划实验系统时别再用“基站设备”的思维约束自己要按“服务实例如何编排、服务间接口如何设计”来拆。2.2 空天地一体化从“覆盖补盲”变成“整网设计”6G网络架构里空天地一体化是雷打不动的关键词。5G阶段卫星通信是给地面网补盲的手机直连卫星属于应急场景6G的白皮书普遍把“天基接入、空基平台、地面蜂窝”作为统一接入资源池来看待。用户从一个地面基站切到低轨卫星再切到无人机平台这个集合内移动性管理、路由策略、QoS保障都必须统一设计。落地时最常踩的坑是“只加卫星不改造核心网”。卫星接入不只是新空口还涉及星间链路组网、星上处理与地面核心网的融合、多颗卫星之间的切换决策。仿真评估这个方向时要把网络拓扑建模成“多层、动态节点”的图结构而不是一张静态蜂窝拓扑。2.3 AI原生从“外挂工具”变成“内建设施”5G网络里AI大都是外挂异常检测、负载预测、告警收敛训练好模型再接入运维系统。6G网络架构把AI提升为原生能力空口波形选择、调度决策、网络切片编排、故障自愈都可能由AI直接参与决策不是辅助人类做判断。设计上要区分“AI辅助”和“AI决策”两个层级。前者人类可干预后者AI直接发指令给网元。白皮书的架构展望里AI内生组件通常会有一个“意图输入接口”和“策略输出接口”的抽象描述落地时这一层要单独做黑匣子测试。AI模型跑得再快没有可解释性运营商不会把控制权完全交出去。2.4 “智简”趋势协议栈做减法为什么反而更难6G网络架构里有一个容易被忽略的词汇——“智简”。意思是协议层要做减法减少层级、减少字段、减少冗余控制。5G空口协议栈从LTE的4层精简到3层6G的目标是进一步把控制面的信令流程压缩部分流程可能直接用AI模型预测代替多次握手。这个方向对从业者是反常识的减法比加法难。减掉一个字段意味着网元之间要重新约定语义减掉一个交互流程意味着AI模型要承担原本信令层面的可靠性职责。规划6G架构实验课题时“智简”不应该是“删掉点什么”而是“用什么替代被删掉的东西再进行可靠性兜底”。2.5 一个边界提醒白皮书只写“趋势”不写“参数”读白皮书有个教训不要试图从里面找可以直接配置的参数。白皮书里给出的速率指标、时延指标是愿景不是设计要求。比如“亚毫秒级时延”是端到端的综合目标具体到空口传输时间间隔给多少、核心网用户面节点部署在哪个位置这些要靠实验验证反推。把白皮书当需求文档把参数当“设计空间”而不是“默认值”这是展开工作的前提。3. 落到形态层接入、调度、承载三块怎么选型3.1 接入侧空天地一体化的分层拆解接入侧选型不要一上来就选频段、选波形先把“空天地”拆成接入层、传输层、控制层三层再看问题。接入层地面蜂窝用6G候选频段7-24GHz的厘米波以及92GHz以上的太赫兹频段卫星侧用Ka/Ku频段无人机平台用毫米波中继。传输层星地间链路的数据路由、星间链路的拓扑管理。控制层统一鉴权、统一移动性管理以及跨层的资源调度。这个分层能直接指导评估。评估接入层就看多频段接入下的切换与干扰评估传输层就看动态拓扑下的路由收敛评估控制层就看跨网鉴权流程的时延和信令量。三个层各自建模分别出结论比笼统做一个“天地一体化系统仿真”要靠谱得多。3.2 控制调度侧AI内生网络的三个能力边界AI内生网络的控制调度不是把调度器换成神经网络就完事。要把AI的边界画清楚否则后期验证无从下手。第一AI决策的输入必须标准化。调度器的观测数据来自空口测量、核心网拓扑、业务队列长度这些输入的数据格式、采集周期、时延容忍度都要先统一否则模型训练和推理都是泥腿子。第二AI决策的输出要可回退。AI调度器给了一个决策网元能不能执行执行错了能不能撤回架构上需要一个“决策回执”和“降级策略”。我一般会把AI调度器设计成与现有调度器并行的结构AI决策经过评估后生效评估不通过就沿用传统轮询调度避免单点翻车。第三AI模型的更新不能影响控制面稳定性。模型更新意味着调度行为可能有突变。6G架构里常见做法是把模型版本与网络配置版本绑定新模型先在一个切片内灰度运行再逐步扩大范围。3.3 承载侧确定性网络与算力感知网络的分工6G承载网选型里有两条线容易被搞混确定性网络和算力感知网络。确定性网络解决“时延可预测”的问题比如工业控制场景要求端到端时延抖动控制在几十微秒以内算力感知网络解决“任务在哪里执行”的问题比如一个AI推理任务要选择在哪一层算力节点上跑。两者不是一回事但有关联。确定性网络做到底网络拓扑、时延、队列策略都得确定性算力感知网络做到底路由度量从“最短路径”变成“最短可执行路径”。在6G架构里这两者最终会融合成一张“业务定义网络”业务发起时先描述自身的时延、算力、可靠性需求网络再决定路径和算力分配。选型关键参数可以从两个维度表里抽出来做预算选型维度5G现网基线6G架构目标技术上必须补的环节接入带宽100MHz通道带宽为主1-2GHz通道带宽高性能基带处理与功放效率时延控制端到端1-5ms为主端到端亚毫秒场景用户面功能下沉至接入点、确定性队列调度路由粒度粗粒度隧道/切片算力感知、业务感知路由度量扩展、算网一体控制面AI能力管理面辅助控制面原生决策可解释模型、决策回退机制拓扑形态静态为主动态星地融合移动性管理重构、星间路由3.4 接入网侧的一个选型参考用户面功能下沉到什么程度5G时代UPF下沉到地市已算激进6G架构里用户面功能可能直接下沉到接入点侧时延链路被压缩到极限。下沉程度直接决定投资规模全下沉到站点回传和机房改造成本剧增只下沉到边缘汇聚节点时延优化不够充分。我建议的评估方式是做“两到三档下沉”的对比接入点下沉一档、汇聚节点下沉一档、区域中心下沉一档测覆盖场景下的时延、抖动、传输成本三个指标再根据业务需求决定档位。这个结论不是白皮书给的是需要实验跑出来的。4. 把白皮书变成可验证的架构从仿真到现网共存的落地路径4.1 先建基线信道模型与仿真场景怎么选6G架构验证不能一上来就建大而全的系统先做基线测试。基线的目的是确认仿真环境和理论预期对齐避免后面所有结论都被错误的起点带偏。常见的做法是选系统级仿真平台搭一套含6G候选频段的信道模型。太赫兹频段的信道特性和毫米波差异很大大气吸收损耗、阻挡损耗、窄波束对准误差都要单独建模。仿真场景参数表可以这样建仿真参数城市场景郊区场景星地场景频段28GHz / 140GHz28GHz20GHzKa信道模型3GPP类UMi/UMa扩展UMa扩展NTN信道模型用户移动速度3-60km/h30-120km/h高速运动卫星平台节点密度500-1000用户/km²100-300用户/km²稀疏但有动态拓扑基线指标频谱效率、接入成功率覆盖、切换成功率切换时延、链路中断率这套参数建完后先跑基线场景确认仿真结果与文献或前期实测的误差在可接受范围。这一步是校准过程不能跳。4.2 建完基线后选一个具体场景做架构重排基线验证完成后不要贪多选一个具体场景做架构重排。推荐选“低时延本地算力调度”场景因为这个场景能同时拉动接入、承载、控制面三个层的架构改动。一个可复现的落地路径是这样做先定义业务模型——一个工业视觉检测任务图像在本地采集AI推理在边缘算力节点执行结果回传执行机构。这个业务对时延的容忍度设定为10毫秒以内。然后做两步改造第一步用户面功能下沉到接入汇聚点把数据绕行距离压到最短测出基础时延 第二步网络控制面增加算力路由功能调度策略从“选最短路径转发”变为“选算力充足的节点执行任务后再回传结果”比较两种策略的端到端时延与算力利用率。这一步做完就能直观感受到“算网一体”对架构的实际影响。4.3 切片先行与5G现网共存的第一条路6G架构不可能等标准完全冻结再部署。在现有5G网络上验证6G相关特性最稳妥的路径是网络切片。切片隔离出独立资源域把6G试验网当作一个增强切片接入现有核心网。实践上要注意三点权限边界切片内可以改调度策略但不要改与现有5G切片共用的底层承载切片内可以部署新的控制面逻辑但必须通过已有NSSAAF接口与5G核心网交互切片内可以试验AI调度器但不能把测试流量引到现网生产通道。这个边界是血泪经验——踩过一次交叉调度的坑现网数据被试验流量干扰最后排查了三个小时才定位。4.4 关键验证指标表衡量“架构能跑”而不是“演示能看”做架构验证时容易被演示效果带偏跑通一个DEMO就算成功。真正衡量架构质量的指标要更细建议按这张表来验收验证层面核心指标可接受基线说明接入层切换成功率 ≥ 99.9%5G基线水平空天地跨网切换成功率控制面信令负载增量 ≤ 10%相比5G基线引入AI内生后控制面开销不失控用户面端到端时延满足业务阈值业务指定阈值低时延场景重点指标可靠性决策回退触发时业务中断率 0%必须为零AI决策失效时刻业务不受影响资源效率算力利用率提升 ≥ 15%相对固定调度基线算力感知路由的收益量化这套表用下来的经验是验证结论必须落到数字上。“提升了”“改善了”不算数“从16毫秒降到9毫秒”才算数。5. 6G网络架构实践避坑五个常见翻车点与排查思路5.1 用5G指标直接套6G验证结果“一切正常”但毫无意义现象仿真环境跑完所有指标都在预期范围内结论看起来漂亮但实际没有任何信息量。 原因验证指标主要沿用5G定义没有针对新架构设计度量。比如只测了峰值吞吐率而6G架构新增的“确定性时延抖动”根本没有纳入观测。 解决在验证指标表里区分“继承型指标”和“新增型指标”。继承型指标沿用5G基线比如频谱效率新增型指标针对本架构改进点比如AI决策回退时延、算力路由命中率、跨网切换成功率。每个架构变量至少匹配一个新增指标。5.2 空天地一体化被窄化成“加一条卫星链路”现象评估单颗卫星覆盖和多颗卫星切换都跑通了整合到整网评估时链路频繁中断。 原因卫星接入只被当作“另一个接入点”接入核心网但卫星移动速度、星间拓扑变化、星上处理能力限制没有纳入控制面设计移动性管理在跨网切换时失配。 解决把空天地一体化拆成三层独立建模接入层做多频段接入传输层做动态路由收敛控制层做跨网移动性管理。三层分别出验证报告再整合评估这样能快速定位中断来自哪个层面。5.3 AI内生模型不可解释演示能看部署被叫停现象AI调度器在线测试时表现很好业务时延明显下降但一到评审阶段运营商侧直接否决。 原因AI模型是黑匣子调度决策无法追溯一旦出现事故无法判断是模型误判还是网络故障责任无法定位。 解决在架构设计里增加“可解释性基线”。AI决策时同时输出决策依据和置信度置信度低于阈值时自动回退到传统调度。这一步加了之后评审通过率明显改善。这不是技术上更先进但它是落地必需的。5.4 仿真环境与实地测试偏差大“实验室优秀、外场翻车”现象仿真环境里端到端时延、切换成功率全部达标外场测试时性能下降明显。 原因仿真场景参数设得太理想。信道模型用的是静态LOS路径外场有明显遮挡移动模型设成匀速直线外场有大量随机停留和转向。 解决做室外评估之前先做“场景敏感性测试”。把信道环境设为LOS/NLOS混合、把用户移动模型换成随机路点模式、把业务模型从恒定码率换成突发码流跑出指标浮动区间。室外测试结果落在区间内说明环境差异导致落在区间外说明仿真模型本身有问题。这套排查流程能省掉大量现场定位时间。5.5 政企项目里“架构展望”被当成“立即部署方案”推销现象项目团队拿白皮书内容向客户汇报承诺6G特性马上能用客户要求部署时间表最后只能用5G现网能力打包交付。 原因白皮书是展望文档不是工程规范。展望到落地之间还差标准定义、原型验证、设备商用三到四步。 解决在对外汇报时明确标注每个6G特性的“成熟度等级”已商用、标准制定中、实验验证中、概念阶段。与客户约定时只对“已商用”和“标准制定中”的能力做承诺其他能力一律作为研究储备。这类项目翻车十有八九是定位错位问题不是技术问题。6. 用“架构变量矩阵”验证白皮书设想一个可复用的评估方法读完白皮书后最大的风险是可陈述的很多可验证的太少。我现在收口的方法是在建任何仿真、写任何方案之前先把白皮书里的每个架构特征转成一个“可验证问题”放到矩阵里逐行过。架构变量矩阵按五列建架构变量、验证问题、对应场景、关键指标、判断阈值。以“全服务化接入网”为例验证问题是“RAN服务拆分后新增一个服务实例的编排时延是多少”对应场景是“边缘算力弹性扩缩容”关键指标是“服务部署时延、Control面信令量”判断阈值是“服务部署时延设定在百毫秒以内信令量不高于现有Ng接口”。这个方法的工作量不大但价值很高。矩阵建完一眼就能看出哪些变量已经说清楚了哪些还是空泛愿景。白皮书的所有章节都能用这个方式过一遍——花一下午把矩阵填完就知道团队该往哪里投入研发资源了。另外提醒一点架构变量矩阵不是一次建完就扔它要跟着验证结果迭代。某个变量的假设被实验推翻时不要只改结论要回到矩阵里修订问题描述和指标定义。梳理完矩阵再根据矩阵优先级安排课题和预算就不会出现“读完整本白皮书、做了几个Demo、最后不知道沉淀了什么”的局面。这套做法帮我避开了不止一次方向性返工希望帮到你。本文还有配套的精品资源点击获取