6G网络架构设计实战:三层四面与四个网络单元详解
简介:这份PDF白皮书由中国电信研究院与中兴通讯于2023年联合发布,面向通信网络研究者、架构师及高校师生,系统探讨6G网络的设计理念、总体架构与创新特征,为理解下一代通信网络提供前瞻性参考。资源包内仅含1个PDF文件,大小约2.65MB,内容完整覆盖从设计思路到业务落地的全链条论述。白皮书共六章:设计思路阐明架构基本原则,总体架构从全局视角划分逻辑功能层面,新架构思考提出网络控制单元NCU、报文处理单元NPU、数据单元NDU与智能单元NIU等新型功能实体,核心特征则聚焦架构极简、用户数据为中心、智能内生与分布自治四大方向,并进一步讨论沉浸式XR、元宇宙、空天地一体及自治专网等业务场景的支撑方式。目前已有360人学习,适合需要把握6G架构演进脉络、开展技术预研或撰写相关材料的读者参考。
1. 从一份白皮书到可交付的架构方案:6G 网络设计到底要解决什么
做毕设或课程设计时,最怕拿到一个宏大题目却不知道从哪落地。6G 网络架构展望白皮书这类材料,表面看是行业前瞻,实际对做方案的人价值很大——它把“未来网络该长什么样”拆成了设计原则、总体架构、功能单元、核心特征、业务场景五层,正好对应一份完整设计文档的骨架。面向 2030 年,沉浸式 XR、元宇宙、空天地一体这些业务对网络的要求早已超出“连接”本身,还需要边缘算力、环境感知、网络 AI 服务。这份方案要解决的核心问题就是:如何用一套极简、数据驱动、智能内生的架构,把连接、算力、感知、智能打包成一体化服务交付出去。适合正在做通信方向毕设、课设,或需要输出网络架构交付方案的人直接参考结构。
2. 总体架构设计:三层四面与四个网络单元的职责划分
2.1 三层四面:从全局视角切分网络逻辑功能
白皮书给出的总体框架是“三层四面”。三层自下而上分别是云网资源层、网络功能层、应用使能层。云网资源层承载各种计算(CPU、GPU、FPGA)、存储、网络、频谱及专用设施,网络资源以 IPv6/SRv6 承载网为主,负责云化网络功能之间的连接。网络功能层是演进重点,提供“连接+”服务,内部再分为控制面、用户面、数据面、智能面。应用使能层聚合网络服务能力和通用应用组件,通过能力开放、应用使能框架向应用或周边生态提供服务。
云网运营管理贯穿各层,除继承网络管理、业务受理、计费结算外,还引入云网智能编排调度、数字孪生网络管理、基于区块链的共建共享管理等新功能。做方案时,这一层容易被忽略,但验收时评委常问“运营管理怎么落”,提前在架构图里标出这条纵向贯穿线能省不少解释成本。
“四面”是在 3GPP 核心网描述基础上的延伸。控制面负责连接、智能、算力、感知服务的统一控制,涵盖多接入融合控制、鉴权认证、移动性管理、会话管理、策略控制、算力资源调配。用户面支持网络可编程,功能包括隧道管理、数据流识别、业务感知、确定性通信保障、封装转发与流量引导。数据面把数据与业务逻辑进一步分离,统筹管理静态与动态数据,通过标准接口向其他三面开放。智能面是智能中枢,提供数据建模、模型训练、推理决策、知识图谱、反馈评估等功能,既服务网络自身智能化,也服务用户和应用的智能化需求。
2.2 四个网络单元:NCU、NPU、NDU、NIU 的职责边界
网络功能层的落地形态是 DDAA(数据驱动的分布自治架构),简化为四个网络单元。NCU 是网络控制中枢,聚合传统控制面功能,负责驱动任务,完成连接、算力、智能、感知的协同。NPU 继承用户面转发能力,引入用户面可编程,向算网业务感知、确定性通信、自治域互联演进。NDU 是统一聚合的数据面,在 UDR/UDSF 基础上新增网络数据和算力数据,提供标准化信令交互和数据访问通道。NIU 提供 AI 任务调度、推理决策、模型训练、知识仓库等功能,通过分布式学习实现跨层跨域智能。
四个单元之间采用双总线互联:一条是服务化信令总线(SBI),把服务化范围从核心网控制面延伸到用户面 NPU,再向无线接入侧 RAN-CP、RAN-UP 延伸;另一条是新增的数据通道,各单元通过数据通道与 NDU 交互,单元之间的数据传递也走这条通道。这个双总线设计是整份方案的技术亮点,做答辩时值得单独画一张图讲清楚“信令走 SBI、数据走数据通道”的分工逻辑。
| 网络单元 | 对应面 | 核心职责 | 关键增强 |
|---|---|---|---|
| NCU | 控制面 | 连接+算力+智能+感知任务协同 | 数字孪生 UE(DUE) |
| NPU | 用户面 | 数据转发与策略执行 | 用户面可编程、算网感知、确定性通信 |
| NDU | 数据面 | 用户/核心/网络/算力数据统一管理 | 标准数据访问接口、跨域联邦学习支撑 |
| NIU | 智能面 | AI 任务调度、训练推理、知识管理 | 独立 NIU + 内嵌 NIU 协同 |
2.3 双总线互联:信令与数据分离的工程意义
双总线的价值在于把实时性要求高的信令交互和大吞吐量的数据访问解耦。SBI 延续服务化设计理念,满足灵活服务、按需定制的实时性要求;数据通道则把原来走服务化接口的数据查询改为统一数据访问接口,支持异步处理和并发执行。做方案设计时,我一般会在架构图里用两种线型区分这两条总线,并在文字说明里点明“互不影响、可异步并发”这个特性,因为它是后面讲架构极简和流程简化的伏笔。
3. 核心单元实现:四个网络单元的功能拆解与配置示例
3.1 NCU 与数字孪生 UE:以用户为底座的控制逻辑
NCU 包含四个核心部分:基础功能、扩展功能、适配接入、数字孪生 UE。基础功能继承移动管理、会话管理、鉴权、计费等现有能力;扩展功能围绕 DUE 全量数据按需扩展,例如确定性连接增强、算网协同、定位感知一体化;适配接入针对不同制式终端提供适配器,实现新老终端即插即用;数字孪生 UE 以 DUE 为最小管理单元,DUE 拥有自己的数据仓库,动态按需加载 UE 侧数据、网络数据、算力数据及核心数据。
DUE 的设计思路值得在方案里重点展开:原来由多个 NF 组合提供完整能力,现在由单一 DUE 提供,且 DUE 能力可强于物理 UE(PUE)。PUE 与 DUE 交互,驱动 DUE 完成网络任务处理。这种“以用户为底座”的处理机制,直接解决了现有多 NF 各自保存数据导致的数据不一致和存储浪费问题。
下面是一段描述 DUE 生命周期管理的伪代码配置示例,用于说明方案中控制单元如何按需加载用户数据:
# DUE 生命周期管理示意:按需加载用户数据并驱动任务 class DigitalTwinUE: def __init__(self, pue_id): self.pue_id = pue_id self.data_repo = {} # DUE 自有数据仓库 self.loaded_modules = set() # 已加载的能力模块 def load_data(self, data_type, source): # data_type: user/core/network/compute # 从 NDU 按需拉取,避免全量同步 self.data_repo[data_type] = source.query(self.pue_id, data_type) def enable_capability(self, cap): # 扩展功能按需加载:确定性连接、算网协同等 if cap not in self.loaded_modules: self.loaded_modules.add(cap) return f"capability {cap} enabled for DUE-{self.pue_id}" def drive_task(self, task): # 基于全量数据驱动网络任务 return task.execute(self.data_repo)这段代码的关键在于load_data的按需拉取逻辑——DUE 不预先同步全部数据,而是根据任务需要从 NDU 查询对应类型的数据。参数data_type对应 NDU 的四类数据划分,source是 NDU 暴露的数据访问接口。实际方案文档里不需要写这么细的代码,但用一段伪代码把“按需加载”讲清楚,比纯文字描述更有说服力。
3.2 NPU 用户面可编程:从转发管道到可定制处理
NPU 在 UPF 基础上做服务化增强,重点向四个方向演进。用户面可编程方面,采用可编程交换芯片、智能网卡、DPU 异构芯片,实现高效数据处理和功耗降低,同时利用可编程技术实现协议无关性和流表可编程,按需集成网络功能、移除无用协议。算网业务感知方面,构建感知型用户面,新增算力服务感知和算力服务路由能力,基于识别的算网 QoS 实现算网资源一体化调度。确定性通信方面,拉通端网云业,实现 NPU 到无线侧和边缘算力侧的时延、抖动、丢包率可测可视。自治域互联方面,不同自治域 NPU 互联,专网 NPU 和公网 NPU 之间建立隧道,通过公网 NPU 代理实现专网用户对外部网络的访问。
做方案时,用户面可编程这部分容易写成空话。我的做法是给出一张“可编程能力与业务场景对应表”,把协议无关、流表可编程、算力感知路由分别对应到无人机、车联网、脑机协同等实时业务,让评委看到每个能力都有明确的服务对象。
3.3 NDU 数据分类与开放接口:四类数据的组织方式
NDU 的构建原则是网络应用与用户数据分离,每个自治域的数据在本域内存储。数据分为四类:用户数据(接入侧能力、速率标签、实时轨迹、当前网络能力与业务)、核心数据(签约数据、业务策略、业务签约)、网络数据(节点管理数据、运行数据、SLA 数据、切片管理、负载情况)、算力数据(通用算力、异构算力、算力服务数据)。NDU 通过数据通道以 API 形式开放能力,为 NIU 的智能分析提供基础数据,跨自治域数据通过数据通道共享,多自治域数据支持跨域联邦学习模型训练。
数据访问接口的设计是 NDU 落地的关键。下面是一段数据查询接口的示意定义,用于说明方案中 NDU 如何向其他单元开放数据能力:
-- NDU 数据访问接口示意:按用户维度聚合四类数据 SELECT u.user_id, u.access_capability, -- 用户数据:接入侧能力 u.rate_label, -- 用户数据:速率标签 c.subscription_profile, -- 核心数据:签约信息 n.node_load, -- 网络数据:节点负载 n.sla_metric, -- 网络数据:SLA 指标 p.compute_service -- 算力数据:算力服务 FROM ndu_user_data u JOIN ndu_core_data c ON u.user_id = c.user_id JOIN ndu_network_data n ON u.serving_node = n.node_id JOIN ndu_compute_data p ON u.task_id = p.task_id WHERE u.user_id = :target_user;这条查询把四类数据按用户维度聚合,正好对应“以用户数据为中心”的设计理念。实际方案里不一定要写 SQL,但用一段接口定义说明“数据按用户聚合、通过标准接口开放”,能让数据面的设计从概念落到可操作层面。参数:target_user是查询入口,实际部署时由 NCU 或 NIU 通过数据通道发起。
3.4 NIU 智能仓储与分布协同:独立与内嵌的混合模式
NIU 包含三大功能模块:AI 服务功能、智能仓储功能、分布协同功能。AI 服务功能在 NDU 数据感知和预处理基础上,提供模型训练和推理决策,训练层覆盖 LSTM、RNN 等基本方法,未来聚焦联邦学习、迁移学习、多智能体强化学习;推理决策层用于网络资源状态预测、最佳路由建议等。智能仓储功能具备模型仓库和知识仓库,负责管理 AI 服务过程中的数据、模型和知识,模型和知识还会下沉到边缘节点以贴近用户。分布协同功能支持多个 NIU 之间或 NIU 与其他域的跨层跨域协同,通过交互数据和模型参数共同完成训练、推理和决策。
6G 智能架构由独立 NIU 和内嵌 NIU 协同组成。独立 NIU 按 AI 能力、服务场景、覆盖区域、算力资源差异分为聚合 NIU、区域 NIU、服务 NIU、边缘 NIU;内嵌 NIU 在 NCU、NPU、NDU 中增加 AI 能力,提供与本单元职责相关的数据感知、模型训练、推理决策。这个“独立+内嵌”的混合模式是智能内生特征的具体承载,方案里需要说清楚哪些任务放独立 NIU、哪些放内嵌 NIU,通常的做法是按“AI 分析尽可能靠近数据源”的原则划分。
4. 架构极简与用户数据为中心:两个核心特征的量化对比
4.1 架构极简:网元、接口、流程的三重简化
架构极简从三个维度达成。架构简化方面,把 5G 中 AMF、SMF、NSSF、NEF 以及 PCF 和 UDM 的逻辑处理部分纳入单一 NCU,UDM 和 PCF 的静态数据、UDR 数据统一由 NDU 处理,UPF 和 NWDAF 优化增强为 NPU 和 NIU,网元数量从 40 余个减少到约 4 个。公网专网采用相同设计架构,网络单元内部服务支持动态裁剪,NCU 通过服务网格组织提供统一服务发现,通过 DUE 以用户为底座设计处理机制,对外支持卫星、固网、移动、无线等异构接入及 4G/5G 后向兼容。
接口简化方面,网元聚合归一后,原网元之间接口变为内部实现,外部服务化接口从 80 余个减少到约 10 个。同时新建专业稳定的数据通道,与 SBI 形成双总线,数据访问与信令交互分离。流程简化方面,依赖性强的网元聚合后,原网元间信息交互转变为网络单元内微服务处理。注册流程从 25+ 步降到 8+ 步,会话建立从 20+ 降到 4+,切换从 30+ 降到 8+。
| 对比项 | 5G | 6G 新架构 | 简化幅度 |
|---|---|---|---|
| 网元数量 | 40+ | 4+ | 约 90% |
| 服务化接口 | 80+ | 10+ | 约 80% |
| 注册流程步骤 | 25+ | 8+ | 约 70% |
| 会话建立步骤 | 20+ | 4+ | 约 80% |
| 切换流程步骤 | 30+ | 8+ | 约 73% |
这张表是方案里最有说服力的量化材料。做毕设时,评委最常质疑“你的架构凭什么比 5G 好”,把这三个维度的数字摆出来,再补一句“测算基于典型流程的消息步骤统计”,基本能挡住大部分追问。需要注意的是,这些数字来自白皮书的测算口径,方案里引用时要说明是“典型场景测算值”,不要写成绝对承诺。
4.2 用户数据为中心:数据驱动与数字孪生的双轮
用户数据为中心体现在两个方面。用户数据驱动方面,现有用户数据虽名义上集中部署在 UDR/UDSF,但受部署要求、技术实现、厂家互操作限制,大部分数据仍分散在 UDM、PCF、AMF、SMF、NSSF 等 NF 中。新架构通过 NDU 从用户视角重新梳理和分离数据,包括核心数据、网络数据、算力数据,通过聚合处理和分析实现按需定制网络功能,统一标准的数据组织方式便于利用专业数据库技术简化处理逻辑。
数字孪生 UE 方面,现有 NF 按功能逻辑划分,以连接所需功能为设计原则,不利于用户维度管理。NCU 动态构建 DUE 与 PUE 伴生,基于用户进行信令处理和管理。DUE 能拉取全量数据,避免数据不一致;数据仅需一份,减少重复存储和网络资源消耗;DUE 具备驱动 AI 的能力,减少数据收集开销。这两点合起来,就是“基于用户业务需求驱动任务,实现连接+算力+能力整体协同”的落地路径。
4.3 智能内生:分布式架构与五项能力提升
智能内生体现在网络组织和智能服务能力两方面。分布式智能内生架构采用“独立 AI + 内嵌 AI”混合模式,NCU、NPU、NDU 通过内嵌 NIU 具备数据处理和 AI 分析能力,与独立 NIU 组成分布式学习和推理框架,按需动态调配数据、能力和算力资源。NCU 内置的 DUE 还可代理用户独立创建 AI 任务,对业务进行端到端监控保障。这种架构的优势是 AI 分析靠近数据源,独立 NIU 按需收集数据或采用分布式学习传递模型参数,减少通信资源消耗,通过多 NIU 协同实现群智协同。
智能服务能力聚焦五个方面:数据内生(NIU 与 NDU 配合,支持海量多态异构数据的感知收集处理存储)、分布式学习(联邦学习、多智能体强化学习、群体学习)、自主决策(自适应多点协作、动态调整、闭环决策)、知识储备(知识仓库支撑迁移学习、持续学习)、协同开放(跨层跨域 NIU 协同,共享 AIaaS 服务)。做方案时,这五项能力可以做成一张“能力—支撑单元—典型场景”的矩阵表,比逐条罗列更清晰。
5. 避坑与常见问题:架构方案设计中最容易翻车的五个点
5.1 把“三层四面”和“四个网络单元”混为一谈
现象:方案里一会儿说三层四面,一会儿说四个单元,读者搞不清两者关系。原因:三层四面是总体框架的横向分层与纵向分面,四个网络单元是网络功能层内部的具体落地形态,层级不同。解决:在架构章节开头用一句话点明“三层四面是全局视角,四个单元是网络功能层的实现形态”,画图时把四个单元放在网络功能层内部,避免并列展示。
5.2 双总线只画不解释,答辩被问住
现象:架构图画了两条总线,但正文没说明为什么需要两条、各自承载什么。原因:双总线是这份方案区别于常规服务化架构的关键设计,只画图不解释等于没讲。解决:单独用一小节讲 SBI 承载信令、数据通道承载数据访问,点明“信令要实时灵活、数据要大吞吐高效,两者解耦后可异步并发”,再补一句“这是流程简化和接口简化的前提”。
5.3 量化数据直接照搬,没标注测算口径
现象:把“网元减少 90%、接口减少 80%”写进方案却不说明来源和口径,被质疑数据真实性。原因:这些数字是白皮书基于典型流程的测算值,不是实测值。解决:引用时写明“基于典型注册、会话、切换流程的消息步骤统计测算”,并在表格下方加注说明测算边界,避免被当成绝对指标。
5.4 DUE 写成万能概念,缺少与 PUE 的交互说明
现象:数字孪生 UE 部分大谈“以用户为中心”,但没说清 DUE 和 PUE 怎么交互、数据从哪来。原因:DUE 的价值在于“按需加载全量数据并驱动任务”,不讲交互机制就落不了地。解决:补一段 DUE 生命周期说明——PUE 与 DUE 交互驱动任务,DUE 从 NDU 按需拉取四类数据,能力模块按需加载,并用伪代码或流程图示意加载过程。
5.5 智能内生只讲独立 NIU,漏掉内嵌 NIU
现象:智能面章节只描述独立 NIU 的 AI 服务和模型仓库,内嵌 NIU 一笔带过。原因:6G 智能架构的核心是“独立+内嵌”混合,只讲独立 NIU 就退化成 5G 的集中式 AI。解决:明确划分——独立 NIU 提供专用 AI 服务和跨域协同,内嵌 NIU 在 NCU、NPU、NDU 内提供本单元相关的数据感知和推理,按“AI 靠近数据源”原则分工,并说明两者如何通过分布协同功能交互模型参数。
6. 验收与答辩:怎么证明这套架构方案站得住
验收这套方案,核心是回答三个问题:架构是否自洽、简化是否有据、业务是否能映射。我一般会准备一张“验收对照表”,把白皮书的每个设计主张对应到可检查的证据上。比如“架构极简”对应网元数量、接口数量、流程步骤三组对比数据;“用户数据为中心”对应 NDU 四类数据划分和 DUE 按需加载机制;“智能内生”对应独立与内嵌 NIU 的分工表和五项能力矩阵。答辩时按这张表逐项过,比从头讲一遍架构更高效。
| 设计主张 | 验收证据 | 检查方式 |
|---|---|---|
| 架构极简 | 网元 40+→4+、接口 80+→10+、流程步骤降 70% | 对照表逐项核对测算口径 |
| 用户数据为中心 | NDU 四类数据划分、DUE 按需加载 | 检查数据分类是否覆盖用户/核心/网络/算力 |
| 智能内生 | 独立+内嵌 NIU 分工、五项能力矩阵 | 确认每项能力有支撑单元和场景 |
| 分布自治 | 双总线互联、跨域联邦学习支撑 | 检查信令与数据通道是否分离 |
| 新业务支撑 | 虚实通感、全域智联、自治专网三类场景映射 | 每个场景对应到具体单元能力 |
答辩时还有一个技巧:主动暴露一个设计边界。比如说明“本方案聚焦网络功能层,云网资源层和应用使能层只做框架性描述”,这样既显得对方案边界有清醒认识,也能把评委的提问引导到你准备充分的部分。血泪经验是,不要试图把每个细节都讲满,留一个明确的“后续研究方向”比硬答一个没想清楚的问题更稳妥。
从那以后我每次做架构类方案,都会在动笔前先画一张“主张—证据”对照表,确保每个设计点都有可检查的落点,而不是堆概念。希望帮到你。
本文还有配套的精品资源,点击获取