跳转至

深入浅出 O-RAN 技术架构

一文带你看懂 O-RAN 的"前世今生", 以及低轨卫星网络中的 O-RAN 部署范式

Danger

鉴于市面上系统整理 O-RAN 的综述文献极少, 多来自于业界的技术报告; 以及在LEO中, O-RAN 如何部署还是个未定式, 目前更多的还只是论文层面的设想

因此, 这篇文章整理起来相当不容易, 笔者会持续更新

Version 1 (2025-12-02): 撰写 "O-RAN Overview"

  • 先不纠结技术细节, 从宏观上对 O-RAN 有个认识
  • 熟悉对应的专有名词, 了解其与传统RAN的本质区别

Version 2 (2025-12-05) 撰写 "O-RAN Issues and NTN O-RAN"

  • O-RAN 的机遇与挑战
  • NTN O-RAN 背景 / 动机 / 架构 (初步设想, 来自 CoNEXT'25 HARMONI)

Version 3 (TODO) 系统解析 O-RAN 的开山之作

  • 文章: 《Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges》
  • 篇幅过大, 详细整理解读见本站 ORAN-DeepDive

在深入研究 LEO Network 与 D2C 这个方向的过程当中, 我们会越来越多地遇见O-RAN这个名词. (详见 SIGCOMM'22-SpaceCore, NSDI'24-MOSAIC)

alt text

alt text

这篇文章我们将深入讲解现有地面网络O-RAN的演变历史和技术组成, 同时也会介绍一些前沿的内容, 比如: 现有 O-RAN components 如何映射到当前LEO-Network 的组件(CoNEXT'25 HARMONI).

alt text

本文部分参考来源:

有意思的是, 之前读过很多篇关于移动网络/无线网络的经典论文, 以及接触过很多测试平台, 发现他们都来自东北大学的这个组. 这个组聚焦于移动与无线网络的研究, 给出了好几个具有划时代意义的产品 (SCOPE / Colosseum / ns-O-RAN / FABRIC). 同时他们还开了一个专题, 专门陈列与O-RAN有关的工作:

  1. ns-O-RAN 仿真平台 (2023)
    • 在 ns-3 中模拟 O-RAN 5G 系统的工具
  2. 可编程智能流量引导 (2023)
    • 使用 O-RAN 架构在 5G 网络中实现可编程和定制化智能流量引导
  3. O-RAN综述 (2023)
    • 综述: O-RAN 架构, 接口, 算法, 安全性和研究挑战
  4. xApps闭环控制 (2022)
    • 在 OpenRAN Gym 中实现了基于 xApps 的智能闭环 RAN 控制
  5. dApps分布式应用 (2022)
    • 用于 O-RAN 实时推理和控制的分布式应用
  6. OpenRAN Gym平台 (2022)
    • 用于 O-RAN 上 AI/ML 开发, 数据收集和测试的开放工具箱, 支持 PAWR 平台
  7. OrchestRAN网络自动化 (2022)
    • 通过 O-RAN 中的编排智能实现网络自动化
  8. ChARM频谱共享 (2022)
    • 通过数据驱动的实时O-RAN动态控制实现下一代频谱共享
  9. SCOPE原型平台 (2021)
    • 面向 NextG 的开放软件化原型平台
  10. QCell自优化 (2021)
    • 通过深度Q学习实现软件化5G网络的自优化
  11. O-RAN智能与学习综述 (2021)
    • O-RAN中的智能与学习, 用于数据驱动的下一代蜂窝网络
  12. 无人机视频流 (2021)
    • 在5G Open-RAN架构上实现无人机视频流应用
  13. 开放可编程虚拟化5G网络综述 (2020)
    • 综述

O-RAN Overview

Motivation

传统的蜂窝网络(如4G)依赖于单一供应商提供的 "单体基站"(Monolithic Base Station), 软硬件紧耦合, 导致灵活性差, 升级成本高, 且运营商被供应商锁定(Vendor Lock-in), 造成"MNO寡头现象"

alt text

O-RAN 的核心愿景是通过以下四大原则重塑 RAN:

  • Disaggregation: 将基站功能拆分为 不同的逻辑单元
  • Intelligence: 引入 RIC(RAN Intelligent Controller)实现数据驱动的闭环控制
  • Virtualization: 软硬件分离, 在通用硬件(COTS)或云平台上运行网络功能
  • Open Interfaces: 定义 标准化的接口 , 允许不同供应商的设备互操作, 有利于创设"扁平化市场"

Architecture && Key Components

alt text

alt text

  1. SMO
    • 全称: Service Management and Orchestration
    • 负责全网的编排, 管理和自动化
    • 它包含 Non-RT RIC
  2. Non-RT RIC
    • 全称: Non-Real-Time RIC
    • 位置: 部署在 SMO 内部, 时间尺度通常是"秒级"
    • 功能: 策略指导 + 模型训练 + 长期优化
      • 它通过 rApps (运行在 Non-RT RIC 上的应用) 来实现这些功能
  3. Near-RT RIC
    • 全称: Near-Real-Time RIC
    • 时间尺度: 10ms ~ 1s
    • 功能: 近乎实时的无线资源管理(RRM) + 负载均衡 + 切换控制
      • 通过 xApps (第三方微服务应用) 来执行具体的控制逻辑
  4. O-RAN 网元 (基于 3GPP split 架构)
    • O-CU (Central Unit)
      • 负责处理: 高层协议(RRC, SDAP, PDCP)
      • 控制面: O-CU-CP
      • 用户面: O-CU-UP
    • O-DU (Distributed Unit)
      • 负责处理: RLC + MAC + 高层 PHY(High-PHY)
    • O-RU (Radio Unit)
      • 负责处理: 低层 PHY(Low-PHY) + 射频(RF)

In-loop Control && ML Workflow

O-RAN 引入了多时间尺度的闭环控制, 同时还引入了AI/ML Workflow, 这是区别于传统网络的最大特征, 深刻体现了 AI for Network.

alt text

三层 "in-loop" 控制:

  1. 非实时环路 (> 1s):

    • 在 Non-RT RIC 中, 通过 O1 收集长期数据, 训练 AI 模型
    • 通过 A1 下发策略, 适用于切片编排, 长期流量预测

  2. 近实时环路 (10ms - 1s):

    • 在 Near-RT RIC 中, xApp 通过 E2 收集 DU/CU 的实时 KPI, 并下发控制指令 (e.g. 切换决策, 负载均衡)

  3. 实时环路 (< 10ms):

    • 在 O-DU 内部(目前 O-RAN 标准尚未完全开放此层级的 AI 接口, 仍需进一步研究)
    • 涉及调度器(Scheduler)和波束管理

alt text

AI/ML Workflow:

Researchers 一般遵循以下流程进行算法设计:

  1. 数据收集: 通过 O1(批量) 或 E2(流式) 从 RAN 收集数据
  2. 离线训练:
    1. 在 Non-RT RIC 中利用收集的数据训练模型 [模型训练: 离线]
    2. O-RAN 要求模型需先离线训练以避免现网风险
  3. 部署:
    1. 将训练好的模型打包, 在 Near-RT RIC 中作为 xApp 部署 [模型部署]
    2. xApp 在线接收 E2 数据进行推理, 并通过 E2 发送控制信令给 DU/CU [推理]

Dataflow: From user's perspective

与传统一体式基站不同, O-RAN 将基站(gNB)拆分为 O-RU, O-DU 和 O-CU 三个部分

alt text

注意, 在这里我们约定俗成:

  • RU-DU: Fronthaul
  • DU-CU: Midhaul
  • CU-5GC(...): Backhaul

alt text

本节我们以一个最简单的例子切入:

用户将自己的请求发送给WebServer (User: "Hey, Server! 快把《疯狂动物城2》的高清资源给我"), 这一过程数据包与上述 O-RAN Infra 如何交互?

Markdown
1
2
<!-- TLDR Version -->
UE -> O-RU -> O-DU -> O-CU-UP -> CoreNet -> WAN (WebServer)
  1. UE → O-RU
    • 动作: 用户点击网页, 产生 HTTP 请求
    • 数据包在 UE 内部经过协议栈封装: App -> TCP/IP -> SDAP -> PDCP -> RLC -> MAC -> PHY
    • 传输: UE 将模拟射频信号, 通过 Uu 接口(in-air) 发送出去
    • O-RAN 节点: O-RU (射频单元)
      • O-RU 接收射频信号, 将其转换为数字信号(ADC)
      • 关键处理(split7.2x): O-RU 负责执行物理层的低层功能(Low-PHY)
        • 如 FFT(快速傅里叶变换) + 去循环前缀(CP Removal) + 波束赋形(Beamforming)
      • 接口: O-RU 处理后的频域 IQ 样本数据通过Open Fronthaul [U-Plane] 接口发送给 O-DU
  2. O-RU → O-DU
    • 传输: 数据通过光纤或以太网传输, 常使用 eCPRI 或 IEEE 1914.3 协议封装
    • O-RAN 节点: O-DU (分布单元)
      • 关键处理(High-PHY/MAC/RLC): O-DU 接收来自 Fronthaul 的数据, 执行物理层的高层功能
        • 如: 解调(Demodulation) + 扰码(Scrambling) + 层映射(Layer Mapping)
      • 随后, 数据向上传递经过 MAC 层(负责调度)和 RLC 层(负责分段和重组)
      • 接口: O-DU 将处理完的数据包, 通过F1-u 接口发送给 O-CU-UP
  3. O-DU → O-CU-UP
    • 传输: 数据通过 F1-u 接口传输(隧道. 通常基于 GTP-U/UDP/IP)
    • O-RAN 节点: O-CU-UP
      • 关键处理(PDCP/SDAP): O-RAN 将 CU 拆分为控制面(CP)和用户面(UP). 数据流只经过 O-CU-UP
      • 功能:
        • PDCP 层功能: 解密, 完整性验证, 头解压缩
        • SDAP 层功能: QoS 流到无线承载的映射
      • 此时, 数据已还原为标准的 IP 数据包
      • 接口: O-CU-UP 通过标准的 N3 接口(即 NG-u 接口)将数据发送给 5G CoreNet
  4. O-CU-UP → 5G Core (5GC)
    • 核心网网元: UPF (User Plane Function)
    • UPF 接收来自 N3 接口的 GTP 隧道数据包, 解封装出原始 IP 请求
    • UPF 执行路由, 计费, 数据包检测等功能
    • 接口: UPF 通过 N6 接口 将数据发送至外部数据网络 (Data Network, WAN)

O-RAN Raises Some Issues

除了前面提到的架构（SMO/RIC/CU/DU/RU）、接口（E2/A1/O1/Fronthaul）和 AI 工作流之外, 我们还想讲一讲这些技术机构本身, 可能带来的思考. 既是挑战, 也是机遇. [笔者更倾向于机遇]

开放性和解耦虽然带来了灵活性, 但也引入了前所未有的安全挑战:

  1. 扩大的威胁面:

    • xApp 恶意攻击: 第三方开发的 xApp 可能包含恶意逻辑, 故意造成无线资源冲突或服务降级
    • 数据恶意注入攻击: 攻击者可能通过 SMO/Non-RT RIC 注入虚假数据, 污染 AI/ML 模型的训练集
    • 接口攻击: 目前 Open Fronthaul (7.2x split) 的控制面(C-Plane)为了满足极低时延要求, 难以实施复杂的加密, 这可能导致 MIM 攻击

  2. Orchestration:

    • 不同的 xApp 可能具有相互冲突的目标
    • multi-xApp 本质是一个"类分布式系统", 因此 distributed system 里的问题, 这里都有

  3. 需要真实的"大规模无线网络测试环境"

    • AI 驱动, 数据是核心; 仿真测试, 设备环境是核心
      • Colosseum: 世界上最大的无线网络仿真器 (HIL)
      • PAWR 平台: POWDER / COSMOS / AERPAW
      • PS: 这些名词, 在本站 "crowd-sourced platform" 部分均有收录整理
    • Data Factory:
      • 利用这些测试床作为"无线数据工厂", 收集异构场景下的大规模数据集, 用于训练和验证 AI/ML 算法, 解决了运营商数据不公开的难题

O-RAN in LEO Networks

这一部分主要来自 CoNEXT'25 论文 HARMONI: A Holistic Approach to Non-Terrestrial 5G Networking with LEO Satellites: Algorithms, Experiments, and Insights

传统的地面蜂窝网络无法覆盖地球所有区域(如海洋, 偏远地区). NTN, 特别是 LEO Networks, 被视为下一代移动网络的关键组成部分, 能够提供全球无缝覆盖.

在这一背景下, O-RAN 和 LEO Networks 的结合其实非常自然, 在不同维度顺应科技发展潮流.

Challenges:

在 LEO 网络中应用 O-RAN 面临着与地面网络截然不同的挑战, 核心在于: LEO 具有"基础设施层面"的高度动态性:

(1) 基础设施的高速移动性:

  • 在地面网络中，基站固定，用户移动
  • 在 LEO 网络中，作为基础设施的卫星高速移动，而地面网关（GW）和用户相对固定
    • 即使用户本身没有移动，由于卫星的高速运动，用户与卫星之间的连接也会发生高频切换

(2) 昂贵的切换成本:

如果采用传统的"整体式基站"(Monolithic gNB)上星架构, 当用户切换卫星时, 会触发跨 CU (Inter-CU) 切换

这需要与地面核心网(Core)进行信令交互(如 AMF), 导致极高的延迟(比 DU 切换高 4 倍)和信令风暴

比如, 左边是 Monolithic gNB 的切换流程 [InterCU]; 右边是 O-RAN 的切换流程 [InterDU].

alt text

可以很直观的看出:

  1. InterCU 涉及到与 CoreNet 的交互: DU在卫星上, Core在地面上, 这种切换的副作用显然很大
  2. InterDU 则完全在网关内部完成, 只需在网关的 CU 和不同卫星的 DU 之间切换, 大大减少了延迟和信令开销
    • 虽然有一些与CU的交互, 但都是在网关内部完成的, 不涉及核心网

(3) 多维 KPI 的权衡:

需要在包括但不限于以下几点因素找到平衡, 这在动态卫星网络中非常困难:

  • 覆盖范围
  • 吞吐量
  • 延迟
  • 稳定性(即最大限度地减少切换频率和影响)

Solution: CU-DU 分离架构

alt text

  1. Split RAN Architecture
    • GW: CU + DU. 将控制锚定在地面，减少核心网交互
    • Sat: DU + RU. 卫星充当分布式的射频和部分基带处理节点
  2. Interface Standardization
    • IAB (Integrated Access and Backhaul): 利用 5G 的 IAB 技术实现 GSLs 和 ISLs
    • Open Interface: 利用 O-RAN 定义的 E2 接口连接 RIC 与网元，O1 接口进行管理

Core Mechanisms:

(1) 会话锚定与迁移:

  • 将用户会话"锚定"在地面的 GW-CU 上
    • 即使用户服务的卫星发生变化, 只要还在同一个网关覆盖范围内, 逻辑上的基站(gNB/CU)不变
    • 减少与核心网的交互次数 (核心网在地面, DU 和 RU 在卫星)
  • 使得昂贵的跨 CU 切换(需核心网参与)转变为轻量级的跨 DU (Inter-DU) 切换(仅需网关内处理), 大幅降低延迟

(2) 轨迹感知的抢先切换:

  • 利用卫星轨迹的可预测性(通过 TLE 数据), RIC 可以提前计算切换时间点
  • 在切换发生前, 主动 (Proactively) 在目标卫星 DU 和网关 CU 之间建立隧道和承载
    • 这使得切换发生时, 大部分信令交互已经完成, 将对用户体验的影响降至最低