Chapter 4: Radio Access Network¶
这一章不仅是对 5G 基站内部构造的拆解, 更是一部无线接入网(RAN)从"专用硬件黑盒"向"开放软件系统"演进的变革史.
作为物理层空口技术与核心网业务逻辑的枢纽, 本章的核心在于理解RAN重构与迭代的时间线, 以及背后的设计动因:
Monolithic RAN → Split RAN → Software-defined RAN
- 物理形态的重构:
- 传统的基站概念(monolithic base station. 单体式基站)消亡
- 取而代之的是依据实时性要求切分出的 CU(集中单元)、DU(分布单元)与 RU(射频单元) 三级流水线架构
- 控制逻辑的重塑:
- 通过 SD-RAN 引入了类似操作系统的 RIC
- 网络控制不再是固化在固件里的死板代码, 而是变成了灵活可编程的 xApps, 通过标准化的 E2 和 A1 接口 驱动网络运行
简而言之, 本章标志着 RAN 的技术重心从单纯的信号处理(DSP/FPGA), 正式转移到了微服务、云原生与智能控制闭环(Cloud & SDN)的领域.
RAN 处理流水线的功能划分¶
图中将基站描绘为一条管道, 但同样可以将其视为协议栈, 这与 3GPP 定义的5G NR协议栈是一致的
(1) 层次梳理:
从左到右共五层, 关键理解各层职责边界:
| 层 | 核心职责 | 关键特性 |
|---|---|---|
| RRC | 策略配置、转发决策逻辑 | 控制平面, 不处理用户数据 (控制平面) |
| PDCP | IP头压缩、加解密、完整性保护、重排序 | 执行RRC的转发决策 (数据平面) |
| RLC | 分段/重组、ARQ纠错 | 可靠传输 |
| MAC | 实时调度、复用/解复用 | Scheduler是主循环, 决定每个TTI传多少字节给哪个UE (review: 在 ch3 中, scheduler是核心) |
| PHY | 编码调制、FEC | 对接RF |
(2) 技术要点:
- "RRC + PDCP" 共同实现"基站作为转发器"的能力, 如前几章经常提及的: handover, multi-link aggregation, etc.
- 其中, RRC做决策, PDCP执行
- "RRC做决策" 这一过程, 有个专门的名词: RRM (Radio Resource Management)
- ch3 我们花很大比重强调的 scheduler, 实际上是MAC层的核心功能
- Scheduler 运行在 MAC 阶段/层, 图中标记为 "S"
- 作用: 决定每个时间段内向特定 UE 传输的字节数 (review: 影响因素是 CQI 和 5QI)
- 意义: 实现了出站流量的"主环路". aka. 从上游 RLC 读取数据, 调度向下游 PHY 传输
Split RAN 的切分逻辑¶
从前面提到的架构出发, 对比一下 Split RAN 的切分逻辑:
- RRC + PDCP 统称为 CU (Centralized Unit)
- RLC + MAC + High-PHY 统称为 DU (Distributed Unit)
- Low-PHY + D/A Conversion + RF Frontend 统称为 RU (Radio Unit)
注意: DAC 与 ADC
- D/A Conversion 指数模转换, 即: 将数字信号转换为模拟信号的过程
- RF Frontend 指对接RF的过程
这两个名词太《通信原理》, 与我们计算机专业的聚焦中心有些偏离, 因此后文并不会花什么笔墨讲解
PS: 数字信号/模拟信号是什么?
- 数字信号: 0和1的离散信号. 计算机里的都是数字信号
- 模拟信号: 真实的世界几乎全是模拟信号. 如: 声音、温度、无线电波 (5G/卫星)
PS: D/A 与 A/D 转换又是什么?
- D/A Conversion (DAC): 数字信号 → 模拟信号
- 把数变成波(为了传输或发声)
- e.g. 耳机播放音乐、基站发射信号
- A/D Conversion (ADC): 模拟信号 → 数字信号
- 把波变成数(为了计算或存储)
- e.g. 麦克风录音、基站接收信号
从全局视角来看, Split RAN 将 CU - DU - RU 按照 multi-level tree 的形式组织:
- 一个 CU 服务多个 DU
- 一个 DU 服务多个 RU
(1) 实时性要求:
由于无线电传输的调度决策由 MAC 层实时做出, 因此: DU 需要"接近"它所管理的 RUs
具体来说: DU 必须在 RU 的1ms延迟范围内! 因为MAC Scheduler需要实时CQI信息做调度决策. 这决定了DU的部署位置
因此一种很常见的配置是: 将一个 DU 和一个 RU 共置在一个基站内
不过也不绝对, 比如: 商场、校园或工厂, 这些地方就是单个 DU 服务多个 RU
(2) CU进一步CUPS分离:
- CU-CP: 对接核心网控制面(AMF)
- 即上述的 RRC
- CU-UP: 处理用户面数据
- 即上述的 PDCP
(3) front-haul, mid-haul, back-haul:
- front-haul: 前端接入
- RU - DU
- mid-haul: 中端接入
- DU - CU
- back-haul: 后端接入
- CU - 5GC
Review: Local breakout
书中有这样的说法: "one might co-locate the CU and Mobile Core in the same cluster, meaning the backhaul is implemented in the cluster switching fabric. In such a configuration, the midhaul then effectively serves the same purpose as the original backhaul"
这里我们尝试解读一下:
回顾在ch2中我们提到的 Local breakout 概念, 对于 RAN 也是同理
很多时候, 我们把 CU-CP 与 5GC 共同部署在云数据中心, CU-UP 则部署在边缘节点
因此对于 CU-5GC 的 back-haul 链路, 其实是在数据中心中的 cluster switching fabric 中实现
而真正从 cloud - edge 的物理链路, 则是 CU-UP - CU-CP 的 mid-haul
如果把 interface 也画上去, 则是这样的:
CU 的大部分复杂性集中在 CU-CP 中, 下面我们将详细讲解, SDN是如何帮助我们实现 CU-CP 这种高度复杂的控制逻辑与管理的
SD-RAN 架构解析¶
这一章节的动机是:
CU-CP 的复杂性非常高, 传统的基站固件已经无法胜任, 缺乏灵活性与可扩展性. 因此我们需要一种新的架构, 来帮助我们实现 CU-CP 的控制逻辑与管理
因此重点是看看: 原本负责 CU-CP 的 RRC, 应该如何被重构
RRC 的重构: Proxy + RIC¶
RRC被拆分成两部分:
- 3GPP Proxy: 维持与 5GC 的标准控制面接口
- Near-RT RIC: SDN Controller, 运行xApps
- 全称: Near Real-Time RAN Intelligent Controller
- 作用: 开启了一个新的程序化 API, 用于对实现 RAN 用户平面的流水线进行 基于软件的控制
具体一点看"地位":
- Proxy: 仅在 5GC 与 PDCP 之间转发控制包, 提供 5GC 与 UE 通信以实现控制目的的路径
- 人话: 制定决策, 告诉PDCP是 "自己处理" or "转发给别人处理"
- Near-RT RIC: 实现 RRC 控制功能的核心
- 功能: 上述提到的 RRM (Radio Resource Management)
- 形式: 基于 xApps 的 API 接口
Near-RT 与 RT 分别是什么
RT 表示 Real-Time
- Near-RT: control loop 大概在 1ms ~ 100ms
- 用在 CU-CP 的 RIC 中
- RT: control loop 大概在 1ms
- 用在 DU 的 "MAC Scheduler" 中
RIC 上的SDN控制应用: xApps¶
xApps 定义是: "运行在Near-RT RIC上的SDN控制应用"
类比理解: 就像SDN Controller上跑的应用程序, xApps是RIC平台上的"插件式"控制逻辑
- 传统方式: 每个基站只看到本地信息, 各自做决策
- xApps方式: 集中收集全局信息 → 全局最优决策 → 下发到各基站执行
比如对于"干扰管理"应用: 单基站只知道自己的干扰情况, 但xApp能看到整个区域所有基站的状态, 做出全局协调的功率/频率分配决策
(1) Near-RT RIC 有两个关键概念: xAPPs 和 R-NIB
- xAPPs: 运行在 RIC 上的控制应用
- Handover Control. 切换决策优化. RRM应用
- Link Aggregation. 载波聚合控制. RRM应用
- Load Balancing. 跨小区负载均衡. SON应用
- Interference Management. 网络级干扰协调. SON应用
- R-NIB: 全称 RAN Network Information Base. 理解成"共享状态库"即可
- 时间平均的CQI值(对比: DU中MAC保持的瞬时CQI)
- GTP隧道ID、5QI值
- 节点配置、UE状态、链路参数、切片属性
(2) xApps 按"控制粒度"分为两类
- RRM Applications(细粒度控制)
- 全称: Radio Resource Management
- 类型: Scheduling, Handover, Link Aggregation, Bearer/Access Control
- 特点: Per-node、Per-link级别的控制, 即原本分布在各个基站的RRC中实现 (就是最开始 RRC 管理 PDCP, RLC, MAC, PHY 的流水线)
- SON Applications(粗粒度控制)
- 全称: Self-Organizing Network
- 类型: 邻区列表管理(Neighbor List), 区域负载均衡(Load Balancing), 集中参数配置(Centralized Parameter Config)
- 特点: 区域级/网络级优化, 需要全局视野
Near-RT RIC 源于 SDN 设计理念¶
Near-RT RIC基于ONOS (Open Network OS)改造而来. ONOS原本是为有线网络SDN设计的(支持OpenFlow、P4Runtime等接口), 现在被重新定向到SD-RAN场景.
仔细看这张图, 后面的内容都是对这张图的解释:
三个核心微服务¶
| 服务 | 职责 | 追踪对象 |
|---|---|---|
| Topology Service | 追踪固定RAN基础设施 | CU/DU/RU拓扑 |
| Device Service | 追踪移动设备 | UE状态 |
| Configuration Service | 管理RAN全局配置 | 配置参数 |
实现方式: 基于k8s微服务 + 可扩展KV存储
三个关键接口¶
(1) A1 接口 [北向 - 管理面]
OSS/BSS 通过 A1 接口, 连接到 Near-RT RIC
- 作用: 运营商管理面向RAN下发配置和策略 (由于来自运营商, 所以是 Non-RT 的)
- 类比: 相当于云原生世界中的gNMI/gNOI(gRPC Network Management/Operations Interface)
- dataflow: Non-RT RIC → Near-RT RIC
(2) E2 接口 [南向 - 控制面]
Near-RT RIC 通过 E2 接口, 连接到 CU-CP, DU, RU
- 作用: Near-RT RIC控制底层RAN元素
- 核心挑战: 需要对接不同厂商的异构设备
- 解决方案: Service Model抽象
- dataflow: Near-RT RIC → CU-CP/DU/RU
(3) xApp SDK
SDK: Software Development Kit
- 编码转换: SDK负责"翻译"
- E2使用ASN.1格式 (历史原因)
- RIC内部使用gRPC/Protobuf
- 目标: O-RAN希望推动统一SDK, 实现xApp跨RIC平台移植
E2 Service Model 机制¶
每个RAN元素(CU/DU/RU)发布自己的Service Model, 声明它支持哪些功能、暴露哪些参数. RIC通过统一的操作原语与之交互
Workflow:
- RAN Element 将信息通过"Service Model"的形式, 上传给 Near-RT RIC
- Near-RT RIC 再通过"E2 操作原语"对 RAN Element 进行读写操作
- 最后 Near-RT RIC 将"操作结果"下发给 RAN Element
(1) Near-RT RIC 中的四种E2操作
| 操作 | 方向 | 作用 | 示例 |
|---|---|---|---|
| Report | 读 | 请求元素上报特定指标值 | 获取当前PRB利用率 |
| Insert | 写 | 激活用户面功能 | 启用载波聚合 |
| Control | 写 | 激活控制面功能 | 触发切换流程 |
| Policy | 写 | 设置已激活功能的策略参数 | 设置切换门限 |
(2) RAN Element 上传的三种标准化Service Model
| Service Model | 缩写 | 功能 | 读/写 |
|---|---|---|---|
| Key Performance Measurement | E2SM-KPM | 定义可采集的性能指标 | 读 |
| RAN Control | E2SM-RC | 定义可设置的控制参数 | 写 |
| Cell Configuration and Control | E2SM-CCC | 小区级配置参数 | 写 |
复习: RAN的架构演变全过程¶
三层解耦
具体细节看前文, 这里就让gemini帮忙总结一下, 笔者自己看了, 体现了核心, 不过也有些许描述欠佳的瑕疵, 懒得改了, 仅供参考
三个控制环
| 控制环 | 时延约束 | 控制点 | 承载功能 | 典型场景 |
|---|---|---|---|---|
| 外层 | >>1s | Non-RT RIC | 策略下发、ML训练、网络规划 | 根据历史数据训练负载预测模型 (看下面的 ML for RAN) |
| 中层 | 10-100ms | Near-RT RIC | RRM xApps、SON xApps、ML推理 | 基于当前负载做切换决策 |
| 内层 | <1ms | DU MAC Scheduler | 实时调度、即时CQI响应 | 每个TTI的PRB分配 |
Warning
并非所有RRC功能都能上移, 部分RRC功能因时延要求必须留在DU
New: ML控制的分层部署
在这种架构下:
- 推理引擎: 在 Near-RT RIC 上以 xApp 形式运行(满足10-100ms响应)
- 训练过程: 在 Non-RT RIC 或云端进行(无实时性要求)
- 通过 A1 接口完成模型和策略的下发
本章核心名词¶
RAN 处理流水线阶段
| 名词 | 全称 | 功能 |
|---|---|---|
| RRC | Radio Resource Control | 控制平面，配置流水线策略 |
| PDCP | Packet Data Convergence Protocol | 头压缩、加解密、完整性保护、排序 |
| RLC | Radio Link Control | 分段/重组、ARQ可靠传输 |
| MAC | Media Access Control | 缓存、复用、实时调度 |
| PHY | Physical Layer | 编码、调制、FEC |
Split RAN 组件
| 名词 | 全称 | 位置 | 包含功能 |
|---|---|---|---|
| CU | Central Unit | 云端 | RRC + PDCP |
| CU-CP | CU Control Plane | - | RRC |
| CU-UP | CU User Plane | - | PDCP |
| DU | Distributed Unit | 靠近基站 | RLC + MAC + High-PHY |
| RU | Radio Unit | 基站 | Low-PHY + RF |
| Fronthaul | RU ↔ DU | ||
| Midhaul | DU ↔ CU | ||
| Backhaul | CU ↔ Mobile Core |
SD-RAN 组件
| 名词 | 全称 | 功能 |
|---|---|---|
| Near-RT RIC | Near-Real-Time RAN Intelligent Controller | 近实时智能控制器，10-100ms控制环路 |
| Non-RT RIC | Non-Real-Time RIC | 非实时控制器，>>1秒控制环路 |
| RT RIC | Real-Time RIC | 实时控制器，<1ms控制环路 |
| R-NIB | RAN Network Information Base | RAN网络信息库，xApp共享数据 |
| xApp | - | 运行在RIC上的控制应用 |
| RRM | Radio Resource Management | 无线资源管理（细粒度控制） |
| SON | Self-Organizing Network | 自组织网络（粗粒度优化） |
关键接口
| 接口 | 连接 | 功能 |
|---|---|---|
| A1 | OSS/BSS ↔ RIC | 管理平面配置 |
| E2 | RIC ↔ CU/DU/RU | 控制RAN元素 |
| xApp SDK | xApp ↔ RIC平台 | xApp开发接口 |
其他重要概念
| 概念 | 说明 |
|---|---|
| O-RAN Alliance | 运营商主导的开放RAN联盟，目标消除厂商锁定 |
| CUPS | Control and User Plane Separation，控制/用户平面分离 |
| OSS/BSS | Operations/Business Support System，运营商管理系统 |