6G服务化RAN：从基站拆分到端到端重构的演进之路

简介《2022年6G服务化RAN白皮书》由中国移动通信研究院发布是一份面向通信研究者、网络架构师及高校通信专业师生的技术文献系统回应了5G核心网已服务化但RAN仍以集成单体为主的发展痛点。白皮书提出基于云原生技术的端到端服务化RAN总体构想围绕控制面接口服务化、RAN控制面服务化、用户面服务化、深度融合DOICT及激发UE服务化能力五个层次展开设计并对应给出各层次的功能划分与应用价值。关键技术部分按基础设施层、网络功能层、编排管理层展开覆盖云原生、虚拟化、异构计算、服务定义与接口、业务编排及智能运维等技术同时剖析了性能保证、安全性、网络稳定性、标准制定等现实挑战。资源为PDF格式仅1个文件包体大小1.21MB下载即可直接阅读已有215人浏览学习。对6G架构预研、学位论文选题、行业趋势研判或无线网络技术调研而言这份白皮书能提供系统性的参考框架和前沿观点。1. 基站拆开卖还是合起来用服务化 RAN 的路线之争2022 年这份中国移动研究院发布的《6G 服务化 RAN 白皮书》讨论的不是某个基站型号、某段频谱而是“基站还要不要作为一个整体存在”这个根本问题。5G 核心网已经通过服务化架构SBA把网络功能拆成一个个可独立部署的 NF 服务但基站长期保持集成单体形态。业界对服务化 RAN 的普遍担忧是拆了之后空口性能保不住。白皮书给出的反直觉结论是——空口指标不是唯一标准端到端性能、系统稳定性、可用性才是关键。服务化 RAN 真正的价值在于让接入网具备全场景适应能力垂直行业要极简定制、个人用户要差异化服务、DOICT 要深度融合这些需求靠固定功能、点对点接口的基站是扛不住的。本文把白皮书的技术主线拆开设计原则、五个演进层次、基础设施层与网络功能层关键技术、编排管理以及落地时的边界与妥协。2. 从 Cloud RAN 到服务化 RAN为什么“能跑”不等于“够用”2.1 Cloud RAN 铺路但服务能力仍受限白皮书先用 Cloud RAN 的发展论证了“云化是必经之路”。Cloud RAN 的两大核心特征是通用硬件平台COTS与云原生技术。COTS 平台把基带处理从专用板卡迁移到通用服务器实现资源池化共享Kubernetes 和 DevOps 则让 RAN 软件可以像互联网应用一样持续交付。文中给出了一组关键数据预期降低 40% 设备成本、30% 运营成本典型场景下节省整站功耗约 5%。但白皮书明确指出Cloud RAN 只是“平台”不是“服务”。当前 BBU 的最小开发粒度是 CU/DU颗粒度仍然太大。接口方面基站内部、基站之间、基站与核心网之间依旧是点对点专用接口。每引入一个新功能就要在相关接口上做标准化和联调工作量巨大。这里可以类比微服务架构中的“单体应用”把单体基站装进容器并没有消除单体本身的问题只是换了个部署形式。2.2 设计原则避免“分布式单体”的关键约束服务化 RAN 最难的不是技术实现而是怎么切分服务。切不好就会变成分布式单体——表面上拆成了微服务实际上服务之间强耦合、改一个全链路都要动。白皮书给出了五条设计原则其中前三条的工程意义最强。第一条RAN 服务要针对外界需求定义。需求来源包括核心网 NF、接入网节点、第三方应用、UE。这意味着不能站在基站内部功能的角度去定义 API而是站在消费方角度定义“关键请求”。第二条服务要满足“松耦合”和“高内聚”。引用了 Robert Martin 的单一职责原则改变一个服务应该只有一个理由。第三条RAN 服务要尽量保持自身数据独立。如果两个服务需要频繁同步数据那它们本质上就不该拆开。提示判断服务拆分是否合理的快速方法——如果修改服务 A 内部逻辑导致服务 B 必须同步修改说明 A、B 之间存在数据或行为耦合需要重新划界。2.3 服务定义的三个步骤白皮书明确提出目前 IT 领域也没有成熟的微服务拆分算法只能靠方法学。服务化 RAN 的结构化设计路径是三步把外界需求提炼为系统操作参考 5GC 的两种模式request-response 和 subscribe-notify确定分解 RAN 服务把系统操作合理地分配给各个 RAN 服务用代码注释的方式可以这样理解服务定义的核心结构RAN Service Spec (概念模型) ├── service_name # 服务名如 RadioBearerManagement ├── operations # 系统操作集合 │ ├── request-response # 同步调用如查询UE上下文 │ └── subscribe-notify # 异步订阅如测量事件上报 ├── data_ownership # 该服务独占的数据域 └── api_version # 独立版本演进消费方按契约对接这套模型的关键在于操作与数据的归属。每个服务只能操作自己拥有的数据跨服务的数据访问必须通过 API 显式完成而不是共享数据库。这样才能保证服务可以独立部署、独立扩缩容。3. 五个演进层次从 N2 接口改造到 UE 服务化3.1 第一层次控制面接口服务化先动 N2这一阶段最保守也最容易被人接受。gNB CU-CP 整体作为一个 RAN 服务与核心网 NFS 通过服务化接口交互替代传统 N2 点对点信令。收益是跨域功能可以直接互访不必再为每个新功能定义新接口。成本是 CU-CP 内部仍然是单体只是把对外接口从传统信令换成了服务化 API。这个层次可以直接对接到现有 5GC SBA。在协议栈上相当于用 HTTP/2 JSON 承载 NGAP 语义服务发现走 NRF。但要注意这只是“接口服务化”不是“功能服务化”服务颗粒度没有变化。3.2 第二层次RAN 控制面服务化流程从串行变并行第二层次才是真正的服务化 RAN。控制面被拆成多种 CPS 服务白皮书中列出的包括服务缩写服务全称核心职责RBSRadio Bearer management Service无线承载生命周期管理CMSConnection Mobility management Service连接与移动性管理LLSLocal Location Service本地定位计算MBSMulticast Broadcast Service多播/广播分发DCSData Collection Service无线数据采集STSSignaling Transmission Service信令传输通道RESRAN Exposure Service接入网能力开放拆分的直接收益有两个。第一RAN 服务可以与 CN 服务直接互访减少不必要的 AMF 转发。传统流程中终端移动性事件要由 gNB 上报 AMF再由 AMF 决策下发。服务化之后CMS 服务可以直接与核心网的接入管理服务交互路径更短。第二RAN 控制面服务与其他服务之间可以从串行交互转为多方并行交互。传统流程 UE - gNB(CMS) - AMF - SMF - UPF └-------- 串行逐跳转发 ---------┘ 服务化流程 UE - gNB(CMSRES) ---- AMF 服务 └----- SMF 服务 └----- 第三方RES订阅方注意这个图的含义并非所有的交互都改成并行而是 RAN 服务可以同时向多个核心网服务发送请求或通知。比如一个多播业务请求MBS 服务可以同时通知 SMF 建立 QoS 流、通知 DCS 采集该业务的空口质量数据这两个动作互不依赖就不再需要像传统流程那样排队等待。3.3 第三层次RAN 用户面服务化打破 OSI 分层约束这一层是最有想象力也最难落地的。传统协议栈严格遵循分层RLC 只从 PDCP 收数据MAC 只从 RLC 收数据跨层调用是不被允许的。服务化 RAN 把用户面拆成 UPS让功能之间的调用不再受限于上下层协议关系。白皮书提出了一个关键动机跨层传输优化。例如高可靠低时延场景下如果 MAC 层 HARQ 重传失败传统实现只能逐层上报最终由 RRC 层决策。服务化之后MAC 服务可以直接调用 RRC 服务中的重配能力或者直接触发 PDCP 层的重复包检测减少端到端时延。用户面服务化的真正难点在于性能预算。用户面是数据通路每个服务调用都带来额外的序列化/反序列化开销和内核态/用户态切换。白皮书承认这条路要依赖硬件加速与云原生技术缩小性能损失。实际实现时建议将高频调用的功能如 HARQ、调度器保留为进程内函数调用低频跨层调用才走服务化 API。传统协议栈调用链严格分层 PDCP --- RLC --- MAC --- PHY 服务化用户面调用链按需组合 URLLC业务PDCP服务 -- MAC服务跳过RLC └-- PHY服务 速率敏感业务PDCP服务 -- RLC服务 -- MAC服务 -- PHY服务这就是“协议无关组合”的思想。但注意不是所有业务的协议栈都能被简化。跳过 RLC 意味着放弃 RLC 的重排序和分段功能这对 TCP 流是致命的。所以用户面服务化必须配合业务感知能力按 QoS 流动态选择协议栈组合。3.4 第四、五层次DOICT 融合与 UE 服务化第四层次是在 RAN 服务化基础上引入 AI 服务、感知通信一体化、计算存储一体化等服务能力。白皮书列举了 AI 任务流拆分服务、策略生成服务、数据处理服务等。这一层与当前 6G 研究中的“内生 AI”呼应本质上把网络能力当作可编排的服务目录。第五层次提出 UE 服务化这在当时是很超前的设计。云手机市场的兴起让 UE 具备算力、测量、信息提供等能力UE 服务UES通过服务化接口向运营商、第三方应用甚至其他 UE 提供服务。比如一辆车可以把自己传感器采集的路况数据作为 UES 发布附近车辆订阅后实现协作感知。这个层次在 6G 时代可能以“终端作为节点”的形态落地当前更多是概念验证。4. 关键技术拆解基础设施、网络功能、编排管理三条线4.1 基础设施层云原生的电信化改造白皮书在基础设施层重点讲了云原生、虚拟化和异构计算。云原生部分对电信行业最有参考价值容器化之后的 RAN 功能需要解决性能隔离和确定性调度问题。核心技术栈如下# 基于 Kubernetes 部署 RAN 微服务的典型资源配置示意 apiVersion: apps/v1 kind: Deployment metadata: name: cps-cms # 连接与移动性管理服务 spec: replicas: 3 # 按信令负载扩缩容 selector: matchLabels: app: cps-cms template: metadata: labels: app: cps-cms spec: nodeSelector: node-type: edge-compute # 调度到边缘计算节点 containers: - name: cms image: operator/ran-cms:6.0.0 resources: requests: cpu: 4 # 预留 4 个 vCPU保证信令处理时延 memory: 8Gi limits: cpu: 8 memory: 12Gi ports: - containerPort: 8080 # 服务化 API 端口这段配置的关键在于资源预留与节点选择。RAN 控制面服务对时延敏感不能像普通 Web 服务一样弹性伸缩。requests必须设置到足以应付峰值信令的 CPU 量否则 Kubernetes 调度会把两个高负载实例放到同一个物理核上导致排队时延不可控。nodeSelector把服务固定到边缘计算节点避免跨数据中心集中调度带来的回传时延。虚拟化方面白皮书给出了完全软件虚拟化、类虚拟化、完全硬件虚拟化的性能消耗对比50%~90%、10%~50%、0.1%~1.5%。这个数据对网络功能设计有直接指导意义用户面功能必须走硬件虚拟化比如 SR-IOV 或 DPU offload控制面可以接受类虚拟化但绝不能做纯软件虚拟化。异构计算的选型可以参照 NVIDIA GPU 的 CUDA、FPGA 即服务FaaS和 DSA/ASIC。在实际规划中MAC 层调度和编解码这类计算密集型功能更适合放 GPU 或 ASIC而移动性管理这类控制逻辑用 CPU 更划算。4.2 网络功能层服务定义与数据处理顺序网络功能层的五个关键技术——服务定义、服务化接口、数据处理顺序、包格式定义、数据包安全、数据采集机制——中最容易被忽略的是数据处理顺序。服务化之后一个 UE 的数据可能被多个服务处理顺序不同会导致语义不同。例如加密服务和头压缩服务必须严格按顺序执行先加密再头压缩否则接收端无法解压。白皮书要求 RAN 服务必须明确定义数据处理的拓扑顺序。工程上常用服务链Service Chain来描述# 用户面数据处理链示例服务化RAN形态 service_chain: name: upf-chain ingress: CPS-LLS # 本地定位服务注入位置 services: - name: packet-filter # 包过滤 order: 1 - name: encryption # 加密 order: 2 algorithm: 3GPP-NEA2 - name: header-compress # 头压缩 order: 3 - name: queue-mgmt # 队列管理 order: 4 egress: UPS-MAC # 出口到MAC服务包格式定义方面服务间传递的数据不能直接套用传统 PDCP/RLC 的字节流格式需要定义带元数据的服务数据单元Service SDU。元数据至少要包含 UE ID、QoS Flow ID、处理时间戳、调试追踪 ID。这样才能支持跨服务的数据关联和问题定位。数据采集机制则可以复用 DCS 服务通过订阅-通知模式向外部暴露无线测量数据避免每个服务各自开发采集接口。4.3 编排管理层业务编排与服务控制服务化 RAN 的编排管理借鉴了核心网的服务注册与发现机制但复杂度更高。RAN 服务有分布式部署、时延敏感、状态强一致三大特点不能直接照搬 IT 的 KubernetesIstio 方案。业务编排的核心是服务拓扑生成。白皮书指出服务化 RAN 要实现 RAN 服务与 CN 服务的一体化编排。一个典型的编排流程如下# 使用服务编排引擎动态生成 RAN 服务拓扑示意命令 ran-orchestrator create-service-topology \ --tenant vertical-automotive \ --services cps-cms,cps-rbs,cps-lls,ups-mac \ # 选择控制面与用户面服务 --interconnect cn-services amf,smf,upf \ # 对接核心网服务 --qos-profile urllc \ --placement edge-zone-a \ # 部署位置 --instantiation-mode parallel # 并行实例化参数说明--services指定该业务需要哪些 RAN 服务--interconnect指定需要对接的核心网服务--qos-profile决定服务链的参数配置URLLC 模式会禁用某些非必要的控制面交互--placement将服务调度到指定的边缘可用区。这个命令背后是服务注册中心和网络切片管理器的联动编排引擎会向 NRF/NSSF 查询可用的 CN 服务实例再生成 RAN 侧的部署清单。服务控制则关注服务的生命周期治理包括弹性伸缩、故障恢复、版本升级。控制面服务适合用 Kubernetes HPA 基于信令负载指标自动扩缩容用户面服务因为状态较大如 HARQ 缓存、PDCP 序号不应频繁扩缩容更推荐用多副本主备切换的方式保证可用性。5. 应用场景验证一套参数两样部署5.1 垂直行业按需精简以港口为例港口场景下网络不需要完整的移动性管理。龙门吊、无人集卡在限定区域运行终端基本不跨区切换传统 RAN 的切换流程反而制造断链风险。服务化 RAN 可以按需组合港口业务服务组合 - CMS关闭无需移动性管理 - RBS开启承载建立 - LLS开启厘米级定位 - MBS可选用于广播调度指令 - DCS开启采集设备运行状态 编排策略把 CMS 服务的副本数降为 0释放出的 CPU 资源分配给 DCS 和 LLS这就是按需精简的价值。传统基站无论业务是否需要所有模块都要运行白白消耗功耗。服务化之后不需要的功能可以直接不下发。实际验证时注意关闭 CMS 服务意味着 UE 不能发生小区切换因此只能用于物理区域严格受限的场景否则必须保留基础移动性能力。5.2 个人用户差异化服务按月租用个人用户的服务化需求更偏体验差异。白皮书设想 UE 可以订阅特定的 RAN 服务比如游戏用户购买“时延优化服务”直播用户购买“上行调度优先服务”。服务订阅流程简化 1. UE 通过 RES开放服务发起服务订阅请求 2. RES 将请求转发给编排管理面 3. 编排面实例化对应服务实例并配置 QoS 参数 4. 用户面服务链动态调整游戏用户优先配置队列管理服务直播用户配置上行调度器服务这里的实现关键在于用户面服务的动态组合不能影响在线用户。推荐使用“先建后拆”的策略先为订阅用户创建一个新的服务实例并验证可用再将流量迁移过去最后销毁旧实例。如果直接在原实例上修改配置一旦参数错误所有在线用户都会受损。5.3 编排管理的一个坑订阅风暴做服务化 RAN 编排时最容易遇到的问题是订阅风暴。大量 UE 或第三方应用通过 subscribe-notify 模式订阅 DCS 数据时服务端会内存暴涨通知消息也可能拥塞信令面。我一般会做两层防护# 限流与批量推送策略 dsc-service configure \ --max-subscribers 10000 \ --batch-interval 200ms \ --batch-size 500 \ --payload-filter ue-list,cell-list第一层是订阅数上限超过后拒绝新订阅并返回 429 状态。第二层是批量通知把 200ms 内的订阅事件合并成一批推送避免每个事件单独触发一条 HTTP 请求。payload-filter可以按 UE 列表或小区列表过滤减少无关数据的下发量。这个方法在 IT 系统里很常见但很多做通信的同行会忽略导致服务化接口一上线就被打挂。验证服务化 RAN 是否达到设计目标可以关注三个指标新功能上线时间从月级降到周级、端到端业务时延看是否通过并行交互缩短、资源利用率看关闭不需要的服务后功耗和设备成本是否下降。这三个指标也是和传统方案 PK 时最有力的论据。本文还有配套的精品资源点击获取