简介由中国电信研究院与中兴通讯于2023年联合发布《6G网络架构展望白皮书》聚焦6G设计理念、总体架构与关键创新面向通信行业从业者、网络架构研究人员及关注下一代网络演进的技术爱好者。全篇共六章从设计思路、总体架构到新架构思考逐步展开重点阐释网络控制单元NCU、网络报文处理单元NPU、网络数据单元NDU和网络智能单元NIU等新概念并基于架构极简、用户数据为中心、智能内生、分布自治四大核心特征系统分析沉浸式XR、元宇宙、空天地一体及自治专网等新业务场景为理解6G愿景落地提供完整框架。白皮书以1个PDF文件呈现压缩包大小约2.65MB内容紧凑、便于携带阅读。目前已有354人学习下载适合作为高校课程、企业预研及技术报告的参考资料。1. 6G网络架构展望白皮书它不是PPT是未来五年网络基建的地基做通信这行的人手里没有几份白皮书是不完整的。但6G网络架构展望白皮书跟5G时代那些动辄上百页的“愿景图”不太一样——它不是在讲“未来有多美好”而是在回答一个非常现实的问题当峰值速率奔着1Tbps、时延奔着亚毫秒、连接密度奔着每平方公里千万级去的时候现有的网络架构哪块先撑不住、用什么方案去替换、替换之后运营商和设备商的组网成本曲线长什么样。这份白皮书适合三类人通读做核心网协议栈的开发者因为你手里的服务化架构很可能是未来十年的过渡形态、搞无线接入网规划的工程师因为通感算一体化会把基站从“管道”变成“基础设施”、以及给管理层写技术路线PPT的方案架构师你需要知道哪些指标是能落地的哪些是留给学术界的。它提供的不是某一种具体设备的设计图而是一套判断技术取舍的坐标系——这篇笔记就围绕这个坐标系展开讲到能直接动手验证的程度。2. 从5G到6G为什么网络架构必须“推倒重来”2.1 5G服务化架构的遗产与天花板5G核心网最大的贡献是把传统网元拆成了“服务化”的模块每个网元提供标准的API接口网元之间通过HTTP/2通信。这个设计让网络功能像微服务一样可以独立升级、按需部署运维效率相比4G的通道式架构是质变。但5G服务化架构的天花板也在这——它本质上是“人设计、人运维”的架构信令流程再优化也是预定义好的状态机遇到动态变化的业务场景时要靠人工策略去拼装拼装速度跟不上业务开通速度。更关键的问题在无线侧。5G接入网仍然是以“小区”为基本管理单位基站之间通过Xn接口做协作切换、干扰协调都是围绕小区边界做的。到了6G通感算一体化意味着基站不仅要管通信还要同时管雷达感知、算力调度、AI推理任务。小区这个概念本身可能要被“服务域”替代——不再是地理上的六边形而是由用户业务需求动态划分的逻辑区域。这种变化不是改改协议栈能完成的接入网和核心网都得换根。2.2 6G的三大驱动AI原生、空天地一体化、分布式自治6G网络架构展望白皮书里反复出现的三个词决定了架构演进的走向。第一个是AI原生AI Native不是“在网络上跑AI应用”而是网络的控制面、用户面、管理面里每个关键决策点都内置AI推理能力——比如无线资源调度不再靠查表式的算法而是用神经网络在线预测业务模型。这意味着架构里必须新增加“分布式AI算力池”这个逻辑网元而不是像5G那样把AI放在网管系统里当外挂。第二个是空天地一体化Space-Air-Ground Integrated Network。6G的覆盖范围不再是地面基站而是要把低轨卫星、高空平台、地面基站、无人机全部纳入同一个网络体系。问题是卫星节点的运动会带来拓扑的频繁变化传统的地面网络路由协议和移动性管理机制根本不适应这个场景——每颗卫星绕地球一圈切换次数是基站切换的几十倍必须设计出全新的控制面逻辑。第三个是分布式自治。6G时代的网络切片数量会从5G的个位数增长到上百个而且每个切片可能有不同的SLA、不同的安全域、不同的算力资源。集中式的网管系统根本管不过来架构上必须支持“每个切片自治运行、局部故障不影响全局”的分布式管理机制。这三个驱动单拎出来任何一个都足以推翻5G架构的某根柱子三个叠加整套体系重写就变成了大概率事件。2.3 架构设计原则从“以网为中心”到“以用户为中心”传统网络架构的设计逻辑是先有网络能力再让用户来适配网络。用户发起一个业务请求网络按固定的流程去响应服务质量取决于网络当时的空闲度。6G架构要反过来——先有用户业务意图网络动态编排资源去满足这个意图。白皮书里把这个原则称为“服务化原生于业务意图”落到架构层面最直观的变化是引入“业务意图层”Intent Layer。用户不直接下发“给我建立一条从A到B的专线”这种技术指令而是说“我要开一场全息会议参会者在上海和深圳需要无损画质”。网络自己去翻译这个意图、规划路径、分配资源并且业务结束后自动释放资源。这种转变会深度影响设备架构。基站不再只是“发射天线基带板”而是一个通用的“边缘算力节点”上面同时跑着通信协议栈、感知算法和轻量级AI推理。核心网的每个服务模块也要从“响应请求”升级为“预测需求”——比如某个区域的业务量即将暴增网络要提前扩容而不是等拥塞告警出来了再人工介入。3. 6G网络架构的关键技术层先看懂“地基”再谈实现3.1 大带宽与通感算一体化频谱效率还能翻几倍6G白皮书一开篇就摆出了那几个“吓人”的指标峰值速率100Gbps到1Tbps频谱效率相比5G提升3到5倍。这些数字不是拍脑袋定的背后有两个技术支点。第一个是太赫兹频段——0.1THz到10THz之间的超宽连续频谱单载波带宽能做到几十GHz但代价是覆盖距离短、穿透能力差。所以6G的物理层设计不会是单一切换到太赫兹而是“低频做覆盖、高频做容量”的混合组网基站要同时支持sub-6GHz、毫米波、太赫兹三套射频组件天线数量从5G的64通道直接跳到1024通道级别。第二个支点叫“通感算一体化”。6G基站不仅要发通信信号还要利用同一个波形做雷达感知——探测周围物体的位置、速度、形状。这意味着基站的信号处理要从“解调用户数据”升级为“同时解调数据和回波”需要在天线阵列的波束管理上增加一套感知模式。业内常见的做法是在帧结构里预留感知时隙通信业务和感知业务时分复用但更激进的方案是同一帧同时做通信和感知用不同的扩频码区分两种信号这对基带处理算力的要求会陡增。3.2 AI原生网络内生的智能不再是外挂5G时代也有AI应用比如智能运维、异常检测但那些都是跑在独立的服务器上通过网络管理接口跟网元对接算“旁路智能”。6G的AI原生是把模型推理直接嵌入到协议栈里而且要求毫秒级的实时决策。最典型的一个场景是自适应调制编码AMC。5G的调制方式选择是按一个固定表格映射信道质量指标和调制阶数到了6G要改为在线学习——模型实时预测信道衰落曲线的下一跳提前把调制阶数改过去。这样做的好处是吞吐量在高速移动场景下能提升30%以上代价是每个基站都要有一块专门跑推理的GPU或NPU而且模型要能支持在线更新。白皮书里对AI原生的架构约束有一条值得特别注意模型管理必须从网管系统下沉到网络功能内部。也就是说核心网的某个网元比如接入管理功能内部要有一个模型注册表和版本管理模块模型发布、回滚、灰度上线都走标准化的接口这是为了保证对模型行为的可审计性。这个设计直接影响设备的计算架构——网元的通用服务器上必须预留专门的AI加速卡槽位不能像现在这样只在机房里额外挂一台GPU服务器。3.3 分布式云与边缘网络算力即服务5G的边缘计算MEC是把算力下沉到基站侧但本质上还是一套独立的计算平台跟通信网络是松耦合的关系。6G要把算力变成网络的原生能力——用户在哪个位置网络就在哪个位置分配算力算力节点的加入或退出要像基站扇区开关一样灵活。白皮书里提出的架构模型叫“算力网格”Compute Fabric每个基站天然就是一个算力节点可以接受来自核心网的计算任务多个基站之间的算力通过智能路由协议做负载调度。比如一个用户在看AR导航他的终端本身算力不够做实时3D渲染网络就在他附近的三个基站里选出算力最空闲的那个来执行渲染然后把渲染结果通过低时延通道推给终端。这带来一个很现实的工程问题算力节点的虚拟化层怎么设计。现在边缘节点的虚拟化基本是轻量的容器运行时但6G要求同一个节点上同时跑通信信令面需要实时操作系统、AI推理任务需要GPU直通、普通计算任务可以用虚拟机隔离三种负载对资源隔离的要求完全不同。常见的做法是引入混合编排器——底层统一用K8s管理容器但通信信令面用独立的高优先级Pod调度策略且通过CPU核绑定保证低时延。3.4 网络编排与自动化:从网元级到端到端5G已经引入了网络切片和网络自动化但切片的编排还是“按模板创建”的思维——管理员事先定义好切片模板用户申请时套模板生成实例。6G的编排要变成“按需动态组合”——不存在预设模板而是在运行时根据用户业务意图用一组原子化的网络功能拼接出一个临时切片。打个比方5G的切片是“组装台式机”选好CPU、内存、硬盘这些既定部件组合起来6G的切片是“按需焊接电路板”——网络功能被拆成更小的原子单元编排器根据业务需求实时决定哪些功能单元放在一起、单元之间用什么接口交互。这个变化对编排器的设计要求很高既要有全局的资源视图所有算力节点、频谱资源、链路负载还要有快速的决策引擎在数百毫秒内完成切片拓扑计算更要有失败回滚能力切片创建中途发现资源不够要把已分配的资源全部释放干净。4. 从白皮书到落地用仿真环境跑通一个6G网络切片的最小验证4.1 搭建仿真环境选择组件与准备数据集6G网络架构还处在标准讨论阶段没有商用设备可买想在真实环境里验证架构方案的唯一途径是仿真。业内常用的做法是结合NS-3网络仿真器和自研的控制面模型NS-3提供物理层和MAC层的信道模型控制面逻辑意图翻译、切片编排、算力调度用外部脚本驱动。我一般会在自己的笔记本上跑最小验证操作系统用Ubuntu 22.04先装基础依赖sudo apt update sudo apt install -y build-essential git python3-dev python3-pip git clone https://gitlab.com/nsnam/ns-3-dev.git cd ns-3-dev ./ns3 configure --enable-tests --enable-examples ./ns3 build这里的--enable-tests和--enable-examples是为了同时编译出官方测试用例方便后续用./test.py -s xxx验证物理层模块是否正常。NS-3默认不带6G所需的太赫兹信道模型需要在后续的src/spectrum/model/里扩展频段参数。如果机器内存小于8GB建议把并行编译参数降一档避免编译时内存吃满。4.2 实现一个最小业务意图驱动切片编排NS-3装好之后我们需要写一个仿真脚本模拟6G架构最核心的能力用户发起一个“低时延感知”双需求业务网络自动创建一条包含通信链路和感知任务的切片。以下是我习惯用的Python脚本框架from ns import ns # 初始化仿真时钟时间步长为1微秒 ns.core.GlobalValue.Bind(SimulatorImplementationType, ns3::RealtimeSimulatorImpl) ns.core.Simulator.Stop(ns.core.Seconds(5)) # 创建节点一个用户终端两个基站节点一个边缘算力节点 terminal ns.network.NodeContainer() terminal.Create(1) base_stations ns.network.NodeContainer() base_stations.Create(2) edge_node ns.network.NodeContainer() edge_node.Create(1) # 给终端配置意图请求50Mbps DLP0.5ms时延附带感知任务 request ns.internet.UdpEchoClientHelper( ns.internet.Ipv4Address(10.0.1.1), 8080) request.SetAttribute(Interval, ns.core.TimeValue(ns.core.MilliSeconds(1))) request.SetAttribute(PacketSize, ns.core.UintegerValue(1250)) # 这里注入一个自定义的“意图翻译”函数 # 把上面这个请求映射为切片参数带宽、算力优先级 slice_cfg { priority: 5, bandwidth_mbps: 50, compute_gpu: False, aim_function: perception } ns.SliceOrchestrator.AssignSlice(request, slice_cfg) ns.core.Simulator.Run()逻辑上这个脚本要做三件事第一创建5G/6G仿真所需的节点拓扑第二把用户的业务请求放进UDP回显客户端里模拟真实报文第三也是关键的调用了自研的SliceOrchestrator.AssignSlice接口这个接口内部会根据slice_cfg里的参数去遍历已经注册的算力节点找到算力足够且路径时延小于0.5ms的那个节点把业务绑定过去。参数说明priority表示切片的调度优先级5表示最高优先级一旦设置底层的无线资源调度器会为该切片预留固定的资源块compute_gpu决定要不要在算力节点上分配GPU容器——感知任务默认不需要GPU因为回波信号处理可以在基带板卡上完成aim_function字段传入perception会触发基站的感知波束配置使该基站同时以3.5GHz频段执行感知扫描。4.3 参数表:6G网络切片仿真必调的五个关键参数仿真跑通之后不能只满足于“通了”要刻意压参数找架构短板。下表是我在不同仿真组合里反复调整后整理的必调参数每一组都直接对应一个架构决策参数典型值范围调整影响架构对应点仿真时延粒度1us / 100us粒度越小越能暴露信令风暴但仿真速度下降十倍控制面时延预算切片优先级1-5高优先级切片会抢占低优先级资源产生抖动分布式自治策略算力节点调度周期50ms / 500ms周期越短算力分配越精准但编排器负载越高算力网格的决策频率感知波束扫描间隔10ms / 100ms间隔越短能耗越高感知精度越大通感算一体化能耗模型意图翻译超时值100ms / 1000ms超时过长会导致业务等待过短导致翻译失败网络功能的服务质量约束建议先按典型值跑一遍再把时延粒度调细、算力调度周期调短观察切片抢占时的行为。如果仿真日志里频繁出现资源冲突告警说明这个拓扑下的调度策略需要改成“先抢占低优先级再扩容高优先级”的混合模式这也是白皮书里提到的“基于意图的资源预取”思想的雏形。4.4 如何验证网络的“感知-通信”同步能力仿真里最容易被忽略的是感知任务和通信任务在时间上的同步。基站执行感知扫描时射频通道会短暂切换到感知模式此时通信信号会被中断如果中断时间超过用户业务的时延容忍度体验就会受损。验证方法很简单在脚本里同时给基站配置“通信符号调度”和“感知符号调度”然后把两个调度器的时钟对齐到同一个Simulator.schedule时间轴上用日志记录每一个时间片归属统计感知扫描导致的通信中断累计时长。如果中断时长超过切片预算的10%就需要在帧结构设计上增加感知时间片的复用机制。这是我踩过最多坑的地方——多数人仿真时只测了通信性能没测感知占用信道的影响结果真实环境里基站一边扫描一边丢包。5. 6G网络架构落地避坑指南从白皮书到工程的五处断层5.1 拿6G峰值指标直接当组网规划输入现象项目组刚拿到白皮书领导就要求按“单用户10Gbps体验速率”来规划回传网络结果算下来核心网带宽需求高得离谱预算直接翻了三倍。原因白皮书里的峰值速率和体验速率是两种东西。峰值速率是在理想传播条件、单用户独占全部频谱资源时的实验室值真实组网时要考虑小区边缘用户、多用户共享频谱、干扰余量实际单用户体验速率通常是峰值的1/10到1/20。解决做容量规划时先按“平均体验速率”而不是“峰值速率”作为输入。比如目标是小区边缘用户体验速率1Gbps频谱效率按6G目标相比5G提升3倍折算算出一个基站需要多少频谱带宽再往上反推回传带宽。不要直接拿1Tbps这种数字做链路预算它会让你做出完全错误的光模块选型。5.2 把“AI原生”做成网管系统里的一个外挂模块现象方案评审时项目组展示的“AI原生网络”是在5G网管系统旁边加了一台GPU服务器通过北向接口获取性能数据做告警预测。原因这是用5G的思维做6G。AI原生网络要求推理发生在网络功能内部也就是每个关键网元接入管理、会话管理、无线调度器内嵌推理引擎。如果只是网管侧加个外挂控制面的决策路径没有变AI模型只能做“事后告警”做不了“事前调度”性能收益极其有限。解决至少要在核心网控制面里新增一个AI推理服务并把无线资源调度器的算法替换成可被模型推理驱动的版本。这一步没有捷径必须在架构里预留模型推理的接口和数据通道这也是白皮书强调“AI Native”而不是“AI Assisted”的根本原因所在。5.3 空天地一体化项目栽在“非地面节点的移动性管理”上现象某模拟项目初次搭建空天地一体化仿真用卫星节点接入地面核心网结果测试时发现卫星在波束切换的瞬间会有5到10秒的控制面中断大量会话掉线。原因5G的移动性管理机制是基于“位置区”的——网络先给用户分配一个跟踪区域用户移动时更新区域位置。卫星不是静止的而是“整颗卫星带着波束一起移动”如果沿用地面网络的跟踪区更新流程卫星每绕地球一圈就有几十次切换信令海量信令会导致核心网过载。解决仿真方案改为“卫星侧做移动性终结”——控制面在卫星上增加轻量级移动性会话管理功能用户感知不到切换地面网络只看到一条用户面承载不需要频繁做路径更新。工程设计上需要在卫星平台上预留一部分算力用于承载这个轻量级的移动性管理逻辑不能假设卫星只是“透传信号的高空基站”。5.4 开源仿真工具不支持6G新物理层仿真结果不可信现象我用ns-3默认配置仿真6G大带宽场景发现结果里频谱效率跟5G几乎没区别困惑了很久。原因NS-3的默认信道模型基于5G参数——子载波间隔30kHz、载波带宽100MHz。6G要跑到毫米波和太赫兹频段子载波间隔、带宽、天线阵列规模都要重新配置。默认模型没配这些参数仿真出来的结果当然不体现6G能力。解决改用ns3-mmwave扩展模块并把天线阵列参数重配为8x8等大阵列。太赫兹信道模型如果开源社区还没有成熟模块先以毫米波参数做替代但要在仿真报告里注明模型边界。血泪经验是仿真结果出来后第一件事不是看曲线而是回查物理层参数配置文件确保频段、带宽、调制方式是按6G目标设的不然整个仿真等于白做。5.5 意图驱动的自动化编排缺少“失败兜底”机制现象切片编排器测试时给一个高优先级会话分配算力节点结果该节点恰好过载编排器不断重试把其他低优先级切片也拖卡顿了。原因意图驱动的编排有个天然问题——它只在“成功路径”上做了优化但“失败路径”被忽略了。当资源不足时编排器缺少一个“降级协商”机制不知道是该拒绝服务还是该降级服务。解决在编排器的内部状态机中增加“降级巡检”状态发现节点过载后不直接重试而是先向业务应用回调一个“资源受限”通知由应用决定是接受降级体验还是放弃本次会话。这个兜底逻辑是6G网络能否自治运行的关键它保证了局部过载不会演变为全局故障。6. 验证一个6G架构方案值不值得投入三个压力测试技巧架构方案做完仿真验证之后心里还是没底我通常用三个压力测试来“加压力”如果三个都扛住了这个架构大概能往前走。第一个是信令风暴测试。把仿真里的用户并发数从1000逐步提升到10万观察核心网控制面的时延是否非线性恶化。好的架构时延应该是缓慢增长的曲线如果出现“断崖式”恶化说明控制面存在串行瓶颈要回到设计图上去查是不是某个关键模块成了单点。第二个是感知任务并发冲突测试。让多个基站同时执行感知扫描并且扫描区域部分重叠观察重叠区域的回波信号是否互相干扰。这个问题在真实组网里几乎必然发生架构上必须有“感知资源协调”机制——比如同一区域内的多个基站通过共享的感知时隙表来错开扫描时间而不是各扫各的。第三个是把AI推理时延注入到协议栈里测端到端时延的抖动。AI推理的时间不是固定的可能有时10毫秒有时30毫秒这种随机抖动在传统网络中不可接受。设计方案里要有“推理预算”的概念——模型在算力节点上跑但责任是在一个严格的上限时间内输出结果超过预算就回退到规则算法。我给自己的架构验证卡了一个硬标准端到端时延P99抖动不得超过均值的20%超过了就说明AI推理没有和协议栈融合好。这三个测试跑一遍少则两天多则一周但远比拿到一个“看上去完美”的白皮书就放心投入要大得多。我自己吃过最大的亏就是拿默认参数跑了三周仿真最后发现整个仿真只验证了物理层控制面逻辑根本还没测——从那以后每次动手前先写一份“仿真验证清单”把要验证的架构模块、关键指标、最坏情况用例都写清楚再传参。希望帮到你。本文还有配套的精品资源点击获取