简介：《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 服务，白皮书中列出的包括：
| 服务缩写 | 服务全称 | 核心职责 |
|---|---|---|
| RBS | Radio Bearer management Service | 无线承载生命周期管理 |
| CMS | Connection Mobility management Service | 连接与移动性管理 |
| LLS | Local Location Service | 本地定位计算 |
| MBS | Multicast Broadcast Service | 多播/广播分发 |
| DCS | Data Collection Service | 无线数据采集 |
| STS | Signaling Transmission Service | 信令传输通道 |
| RES | RAN Exposure Service | 接入网能力开放 |
拆分的直接收益有两个。第一，RAN 服务可以与 CN 服务直接互访，减少不必要的 AMF 转发。传统流程中，终端移动性事件要由 gNB 上报 AMF，再由 AMF 决策下发。服务化之后，CMS 服务可以直接与核心网的接入管理服务交互，路径更短。第二，RAN 控制面服务与其他服务之间可以从串行交互转为多方并行交互。
传统流程： UE -> gNB(CMS) -> AMF -> SMF -> UPF └-------- 串行逐跳转发 ---------┘ 服务化流程： UE -> gNB(CMS+RES) ----> 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 的 Kubernetes+Istio 方案。
业务编排的核心是服务拓扑生成。白皮书指出，服务化 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 时最有力的论据。
本文还有配套的精品资源，点击获取
