简介《2022年6G服务化RAN白皮书》由中国移动研究院发布面向6G网络架构研究者与通信工程师旨在探讨无线接入网从传统集成单体向服务化转型的方向与路径。文档首先梳理5G服务化架构集中于核心网的现状继而提出服务化RAN五个层次的设计构想并讨论云原生、虚拟化、网络切片、边缘计算等使能技术以及性能、安全、标准化等落地议题。压缩包仅含1个PDF文件大小约1.21MB便于直接下载阅读当前已有216人学习。内容从Cloud RAN演进到终端服务能力开放均有涉及并给出发展挑战与标准化思路可作为理解6G服务化网络架构的入门资料和后续讨论的基础。1. 6G服务化RAN到底是什么先说一个反直觉的结论6G服务化RAN看起来像“把基站搬上云”实际上它要改的不是空口信号的发收而是基站内部管理信令的组织方式。2022年对外发布的那版《6G服务化RAN白皮书》引入了5G核心网SBA的思路把RAN里的RRM、移动性管理、UE上下文管理、测量控制这些功能从专用接口里释放出来变成可独立注册、发现、调用的服务。读这份白皮书的直接价值在于判断一条路线现网CU/DU要不要拆网络切片粒度能不能更细AI能不能作为一等公民嵌入RAN流程。适合三类人看做RAN产品规划的、写协议栈的、以及需要评估6G网络架构方向的研究生。接下来我会按“为什么这么改 → 架构怎么拆 → 原型怎么搭 → 坑在哪 → 怎么验证”的顺序把它讲透。2. 从5G核心网SBA到6G服务化RAN一张对比表和三个驱动力2.1 服务化的本质把“接口”换成“服务”传统RAN网元之间靠点对点接口通信比如F1、Xn、S1消息流程是事先定死的。A网元想给B网元传个上下文必须按接口规范里写好的步骤逐条走加一个新功能就得改接口定义两边的实现还要同步升级。服务化的思路完全不同把网元能力抽象成一个个API服务生产者把“我能干什么、地址在哪”注册到统一目录服务消费者启动时查目录、按需调用运行时还可以订阅状态变化通知。功能不再按网元边界隔离而是按服务粒度组织。对比项传统RAN专用接口服务化RAN接口对接方式点对点消息流程服务注册、发现、调用耦合度强接口版本绑定弱服务可独立演进新功能上线改接口流程两端联调新增服务或新版本API网络切片支持靠专用网元承载靠服务组合动态编排时延预算微秒级到毫秒级可控需分级设计不能一概而论运维调试单一厂商闭式联调跨厂商、可观测性要求高RAN里并不是所有功能都适合服务化。我判断的标准很简单凡是处在无线数据面快速路径上的功能比如物理层调度、HARQ、波束管理都不拆拆了就是给自己找麻烦适合拆的是控制面里的管理类功能它们对时延容忍度高天然需要灵活组合。2.2 三个驱动力切片、AI与云原生这份白皮书不是凭空画架构它背后有明确的业务压力。第一个驱动力是网络切片。5G的切片主要靠核心网做隔离RAN侧基本还是“一套配置打天下”。到了6G切片要按工业、车联网、XR这种场景动态组合RAN必须能把调度策略、移动性策略、测量配置拆成可插拔的服务切片才能下探到空口。第二个驱动力是AI与通信融合。白皮书反复强调内生AI意思是推理能力不能挂在RAN外面当外挂而要作为RAN内部的服务存在。比如把模型推断、训练数据采集、模型生命周期管理做成RAN可以订阅的服务让AI参与波束预测、负载均衡、干扰协调。这个需求用传统接口很难承载因为传统接口传输的是信令消息不是模型版本、推理结果这类异步数据。第三个驱动力是云原生基础设施。6G RAN会被部署在通用计算平台上容器、Kubernetes、服务网格成为常态。网元一旦容器化扩容缩容就不是整机拉起而是服务副本增减服务化架构和云原生的管理模型天然匹配。2.3 收益与代价没有白拿的灵活性服务化带来的收益很直观设备商可以独立迭代某个服务运营商可以按需组合功能AI能力可以作为服务被RAN和核心网共用。但代价同样真实。服务化意味着原来一次RRC信令就能完成的操作现在可能要多走一次服务发现和调用网元之间的信任边界也需要重新设计。这套架构用不好就会变成“三层封装、四层代理、五层无意义”。我为团队定的原则是分级时延敏感的本地功能用轻量直连跨网元的非实时功能才走服务化目录。白皮书的主旨也不是把RAN拆成一堆碎服务而是把“哪些该拆、哪些不该拆”的判断标准摆到了台面上。3. 6G服务化RAN的架构拆解服务清单、注册流程与接口演进3.1 从CU/DU到服务集控制面功能怎么重新分组6G服务化RAN仍然保留C-RAN的物理切分基础集中单元CU、分布单元DU、远端单元RU。服务化改造的重点集中在CU侧控制面也就是把传统CU-CP里的进程按功能边界拆成服务。我对照白皮书思路梳理过一份最小可用的RAN服务清单按消费者和时延敏感度分类服务名称负责功能生产者网元主要消费者时延敏感度QoS策略服务切片QoS参数翻译与下发CU-CPDU、核心网中UE上下文管理服务UE接入上下文创建、更新、释放CU-CPDU、CU-UP高移动性管理服务切换决策、切换准备与执行CU-CPDU、核心网高测量控制服务测量配置、测量报告聚合CU-CPDU、UE(经DU)中干扰协调服务小区间干扰协调策略CU-CPDU低模型推理服务AI模型部署、推理结果分发边缘算力节点CU-CP、DU低至中无线调度执行实时调度决策DU本地无本地直连极高不服务化这张表对我的价值在于回答一个实际问题如果把所有功能都注册成服务光服务间握手就能把控制面压垮。我一般把“无线调度执行”留在DU本地它不注册、不入目录只通过内存或共享数据面通信。3.2 服务注册、发现和订阅RAN侧NRF怎么工作服务化架构里最核心的机制就是注册与发现。5G核心网有NRF网络功能仓库功能RAN侧白皮书沿用同样理念但部署方式更灵活可以是独立网元也可以和核心网NRF逻辑共用。一个典型流程走五步服务生产者启动后向注册中心发送注册请求上报服务名称、版本、端点地址、能力属性。注册中心校验服务身份与权限写入服务目录返回确认。服务消费者启动时向注册中心发送发现请求查询目标服务地址。注册中心返回匹配的服务实例列表消费者按负载或时延选择实例。运行时消费者订阅服务状态变化服务异常下线后能及时感知并切换。在原型验证里我通常把注册中心简化成带心跳超时的KV存储服务实例每10秒上报一次心跳超过30秒认为下线。生产环境才需要引入NRF级别的状态同步和多实例选择策略。3.3 接口演进F1/Xn与SBA怎么共存服务化RAN接口不是突然把F1、Xn全删掉重来。白皮书给出的态度是演进与共存RAN内部控制面接口可以逐步服务化比如F1-C承载在HTTP/2上Xn控制面按服务化API重写但RAN与UE之间的空口、与核心网之间的N2/N3接口仍保留传统语义。这样设计的原因很实际。空口协议栈牵一发而动全身短时间内不可能改核心网侧N2的NGAP已经在向服务化演进两边正好对齐。对于存量设备需要一个“服务化网关”做协议转换对外暴露传统F1/Xn对内映射成服务调用。我验证过这个共生方案的可行性控制面消息从“专用流程”变成“HTTP请求JSON载荷”之后单条消息体积变大但流程编排灵活得多。代价是接口的调试习惯要变以前一条信令一个包就能看懂现在一个操作可能要追踪一组服务调用链。3.4 把现有网元映射成服务清单的操作步骤如果你拿到一份白皮书不知道该从哪下手我建议按下面步骤把现网架构映射一遍画出当前CU-CP的所有控制面模块和它们之间的信令依赖。标出每个模块的被调用频率与时延预算高频率低时延的标记为“不拆分”。把剩余模块按“管理类”“配置类”“决策类”分组每组对应一个候选服务。定义每个服务的注册属性服务ID、版本、支持的操作、订阅事件。对照现网接口找出哪些信令流程可以被服务调用替代哪些必须保留。这套映射做完你就能判断白皮书的方案在自己当下项目里能落多少。我见过不少团队卡在第三步原因是不敢把老功能拆开怕影响既有联调。实际上按服务边界重新分组反而能让多厂商对接时各管一段。4. 照着白皮书思路搭一个最小服务化RAN原型注册、发现与调用4.1 最小原型需要哪些模块做原型不用一上来就碰射频和物理层。服务化RAN验证的核心是控制面信令闭环我习惯用一个极简组合注册中心、一个RAN控制面服务、一个模拟DU消费者。注册中心负责模拟NRF能力原型里用NATS或etcd都能胜任。RAN控制面服务可以用Go或Python写跑在容器里。模拟DU则是一个定时向注册中心发现服务、然后发起调用的脚本。整体不碰真实空口只验证“服务能注册、能被发现、调用结果能返回”。选Go还是Python取决于你要验证什么信令交互逻辑用Python最快协议栈接口形态建议用Go性能压测才需要C实现。我自己做闭环验证偏好Python代码量少改起来快。注意最小原型不等于商用实现。跳过无线帧级调度、物理层处理这些实时部分是刻意取舍别拿它衡量服务化RAN的真实性能。4.2 跑通注册、发现与调用的最小闭环下面这段Python模拟了服务生产者注册和消费者发现的过程可以直接跑import json import time import requests NRF_URL http://127.0.0.1:8080 # 本地原型里的注册中心地址 def service_register(service_id, endpoint, ttl30): # service_id: 服务唯一标识例如 ran.rrm.ue_context_manage.v1 # endpoint: 服务生产者暴露的地址例如 http://127.0.0.1:5001 # ttl: 心跳租约时间超过该秒数未续约则服务被自动剔除 body { service_id: service_id, endpoint: endpoint, ttl: ttl } # 注册接口设计为 PUT幂等重复注册会刷新租约 r requests.put(f{NRF_URL}/v1/services/{service_id}, jsonbody, timeout1) return r.status_code 200 def service_discover(service_id): # 消费者查询服务目录返回可用实例地址列表 r requests.get(f{NRF_URL}/v1/services/{service_id}, timeout1) if r.status_code ! 200: return [] return [item[endpoint] for item in r.json().get(instances, [])] if __name__ __main__: # 生产者注册一个UE上下文管理服务 ok service_register(ran.cu_cp.ue_context.v1, http://127.0.0.1:5001, ttl30) print(register:, ok) # 消费者启动后查询该服务地址 time.sleep(1) endpoints service_discover(ran.cu_cp.ue_context.v1) print(discovered endpoints:, endpoints)这里的逻辑是注册中心以service_id为主键存储端点地址PUT请求天然幂等重复注册不会报错只会刷新租约。ttl参数很关键它决定了服务异常退出后多久会被目录剔除。如果ttl设太短网络抖动会导致误删设太长服务真挂了消费者还傻等。原型里30秒合理生产环境一般按心跳间隔的3倍设定。注册和发现跑通之后还需要验证真正的调用。消费者拿到端点地址直接向目标服务发POST请求创建UE上下文# 服务生产者启动监听5001端口 python ue_context_service.py --port 5001 # 消费者发现服务后发起一次上下文创建请求 curl -X POST http://127.0.0.1:5001/v1/ue-context \ -H Content-Type: application/json \ -d {ue_id:001010000001,cell_id:cell_001,slice_id:embb_01}这个请求模拟的就是传统RAN里CU-CP为UE建立上下文的动作。在服务化架构里它变成了一次标准REST调用UE上下文创建流程被封装在服务内部消费者不需要关心内部状态怎么管理。返回结果里会携带服务分配的上下文ID和资源预留信息。调用链路一旦通服务化RAN控制面的核心闭环就成立了。4.3 验证这个原型要看的指标原型跑通后别说“感觉没问题”要看数据。我通常采集四类指标指标采集方式原型预期服务注册时延注册请求计时10ms以内服务发现时延发现请求计时5ms以内心跳超时剔除时间人为停掉服务观察剔除耗时约1.5个ttl周期单次服务调用P95时延压测脚本统计20ms以内不含业务处理对这些指标我有一条底线原型阶段服务化带来的额外开销不能超过50ms否则说明接口定义或序列化方式有问题需要排查是不是JSON序列化太重、HTTP连接没复用、或者注册中心成了瓶颈。我见过一版实现因为每次调用都重新建立HTTP连接P95直接打到200ms后来改成连接池才恢复正常。5. 服务化RAN落地的五个坑现象、原因与绕法5.1 坑一注册风暴让控制面先死现象大量服务实例同时启动注册中心CPU被打满后续合法注册和发现请求全部超时整个控制面雪崩。原因服务启动时集中注册没有做流量控制。这和当年LTE附着风暴很像只是把信令压力转移到了注册中心。容器化平台滚动重启时最容易触发。解决注册请求要做限流和退避重试。服务实例启动后先随机等待0到5秒再发起注册失败时按指数退避重试。注册中心侧做请求排队超过容量直接返回“过载”状态码让客户端自己退避。我还在生产里见过更狠的做法注册中心不主动探活全靠服务端心跳减轻压力和脑裂风险。5.2 坑二服务化时延吃掉调度预算现象调度决策需要毫秒级响应但服务调用链多了两层转发时延直接翻倍空口调度跟不上。原因把本不该拆的功能强行拆成了跨网元服务。无线调度是DU本地的事如果把它做成消费者去远端发现调度服务网络一跳就毁了实时性。解决给服务分时延等级实时功能走本地直连不上注册中心。白皮书的边界画得很清楚真正面对空口的快速路径拒绝服务化。我在设计服务清单时会把“时延敏感度”这一列作为第一优先级凡是标记为“极高”的服务直接排除在服务化改造范围外。5.3 坑三CU-CP与CU-UP服务的状态同步撕裂现象UE上下文在CU-CP侧创建成功但CU-UP侧没收到对应配置数据面建立失败信令流程又回滚不干净。原因跨服务的事务没有保障机制。传统网元内部状态机集中管理拆成服务后一个操作要改两个服务的数据中间任何一步失败都会造成状态不一致。解决先把服务之间的依赖关系画清楚再决定事务边界。UE上下文这类强一致操作不能简单拆成“各自更新”需要引入补偿机制比如CU-UP侧创建失败后CU-CP侧自动发起删除回滚。原型阶段我会用两阶段提交的思想简化实现先写一个本地事务表记录操作意图成功后再异步确认。服务化不是把一致性也“化”掉而是要把一致性边界显式暴露出来。5.4 坑四F1/Xn老接口和SBA双栈运维两套体系现象现网设备走F1协议新设备走服务化API告警、日志、信令追踪全都对不上排障像在两个黑匣子里来回跳。原因服务化改造不是一天完成的新旧接口必然长期共存但运维工具没有跟着升级。传统信令追踪工具只看F1/Xn的协议包服务化侧的问题要看HTTP日志和调用链两套工具互相不通。解决引入一个统一的服务化网关做协议转换同时输出统一的日志格式。每个服务调用都生成trace_id贯穿网关和服务内部让一条UE信令能从传统接口一路追踪到服务调用链。排障时先看trace_id再查具体日志能省掉一半扯皮时间。5.5 坑五AI服务与RAN服务混布整机抖动现象模型推理服务跑在同宿主机上推理峰值时CPU抢占导致RAN控制面服务响应变慢切换流程超时。原因AI推理算力需求和RAN信令处理完全不同一个是突发高算力一个是稳态低时延混布时资源隔离没做好互相拖累。最明显的是CU-CP服务和模型推理服务共享同一批CPU核抢起来毫不客气。解决把AI服务单独池化部署RAN控制面服务与AI推理服务物理隔离。推理服务通过消息队列或订阅机制向RAN服务提供结果不让推理时延直接卡在RAN关键路径上。我在原型里就是用独立容器加CPU配额限制来模拟这种隔离效果明显。6. 用OpenAPI把RAN服务定义变成可验证存根一个收尾技巧读白皮书最容易获得的工程产出不是论文笔记而是一份机器可读的服务定义。我的习惯是把白皮书里描述的服务能力先写成OpenAPI描述文件再自动生成存根代码用存根跑一致性测试。这样既验证了自己对架构的理解也等于提前把服务接口契约定下来了。下面是一段最小化的OpenAPI定义片段对应UE上下文管理服务的创建操作openapi: 3.0.0 info: title: ran_service_api version: v0.1 paths: /v1/ue-context: post: summary: 创建UE上下文 operationId: createUeContext requestBody: required: true content: application/json: schema: type: object properties: ue_id: type: string cell_id: type: string slice_id: type: string responses: 200: description: 上下文创建成功 content: application/json: schema: type: object properties: context_id: type: string把这份YAML交给fastapi或openapi-generator就能自动生成可启动的存根服务。对这个存根做接口测试等于把白皮书里的概念定义变成可执行的契约。每次架构讨论有分歧直接拿YAML改一版再跑测试比开会争效率高得多。我用这个方法吃过一次亏当时急着生成存根没仔细定义错误响应结果模拟DU把超时当成上下文创建失败回滚逻辑被反复触发。后来在OpenAPI里补全了超时和过载状态码测试才稳定下来。所以我会建议你拿到这份2022年白皮书后第一件事不是通读全篇而是挑一个你熟悉的RAN功能写成OpenAPI描述生成存根把它跑起来。这一步做完你对服务化RAN的理解会比只看图深刻得多。整个方向值不值得投入答案也会更清楚。希望帮到你。本文还有配套的精品资源点击获取