## 概述 2018年2月，AT&T、中国移动、德国电信、Verizon几家运营商牵头成立O-RAN联盟，画了一张让整个行业热血沸腾的图：给基站装一个「操作系统」（RIC），第三方开发者在上面跑App（xApp/rApp），AI模型像换应用一样热插拔。七年过去，这场「基站App商店」运动到底开张了没有？谁在生产网上真用上了？本文以[O-RAN联盟官方架构文档](https://www.o-ran.org/)为主轴，结合开源社区与商用网络的公开进展，把RIC的两级控制环、E2接口的真实生态、三条技术路线的分野，从一线运维视角一次讲清楚。结论先行：**商店开了，货架不算满，但操作系统本身正在换代。** ## 目录 - 一、先说清楚：RIC是个什么东西 - 二、两级控制环：rApp慢思考，xApp快反射 - 三、愿景有多美：为什么大家曾为它激动 - 四、七年战报：谁真的在生产网上用起来了 - 五、路线之争：开放RIC、内嵌AI、AI-RAN - 六、一线视角：现在能做什么、该学什么 - 七、结语 ## 一、先说清楚：RIC是个什么东西 干过无线优化的兄弟都懂一个痛：基站是个黑盒。网管上能看到的，是设备商嚼碎了喂给你的KPI——掉线率、切换成功率、PRB利用率，粒度15分钟起步，想拿毫秒级的MAC层原始数据？没有这回事。想在没有人工干预的情况下让算法实时改参数？更没有。 RIC（RAN Intelligent Controller，无线智能控制器）要解决的就是这个黑盒问题。按照O-RAN联盟的架构描述（WG1系列规范，可在[官网](https://www.o-ran.org/)下载），它把无线侧的智能化拆成了两级控制器，部署在SMO（Service Management and Orchestration，服务管理与编排）框架之下： - **非实时RIC（non-RT RIC）**：跑在SMO上，控制环在秒级到分钟级以上，上面运行的应用叫**rApp**。它更像个「军师」，负责策略、模型训练、意图翻译。 - **近实时RIC（near-RT RIC）**：独立部署的软件平台，控制环在10毫秒到1秒之间，上面运行的应用叫**xApp**。它像个「反射弧」，负责实时调度决策、移动性控制、快速异常干预。 两者之间用A1接口传策略，RIC与无线网元之间，O1管配置、E2管实时控制与遥测。E2是整个体系的心脏——标准里定义了一组E2SM服务模型：E2SM-KPM管关键性能测量、E2SM-RC管无线控制、E2SM-CCC管小区配置，后来还陆续补了网络接口监测等。一句话总结这套设计：**把原来焊死在设备商基带软件里的「智能」，抽出来变成可以第三方开发、按需加载的应用。** 对干了十几年运维的人来说，这个抽象不难理解：RIC之于RAN，就像网元操作系统之于业务板卡。问题从来不在概念，在于生态。 ## 二、两级控制环：rApp慢思考，xApp快反射 很多人第一次看O-RAN架构图都会犯迷糊：为什么搞两个RIC？我用一张图把数据流和控制流捋直（架构细节以O-RAN联盟官方规范为准）： ```mermaid flowchart TD A["SMO 管理编排层"] --> B["非实时RIC"] B --> C["rApp 策略与训练"] B -->|A1 策略下发| D["近实时RIC平台"] D --> E["xApp 移动性"] D --> F["xApp 节能"] D --> G["xApp 异常干预"] D -->|E2 控制 10ms到1s| H["O-CU"] D -->|E2 遥测| I["O-DU"] A -->|O1 配置 秒级以上| H A -->|O1 配置| I H -->|F1| I I -->|前传| J["O-RU 射频单元"] ``` 这张图的关键信息有三层： **第一层，时间尺度决定分工。** rApp干的事不着急：训练一个切换参数优化的模型、根据话务预测输出明日节能策略、给某片小区定意图目标。这些活儿分钟级、小时级都来得及。xApp干的活儿都是「等不起」的：UE上报的测量在10毫秒后可能就过期了，一次乒乓切换从发生到恶化成掉线，也就几百毫秒的事。10ms~1s这个窗口，恰好卡在传统网管（太慢）和基带实时调度（太快、且是设备商自留地）之间——这是O-RAN给第三方留出的缝隙。 **第二层，接口成熟度差异巨大。** A1和O1脱胎于成熟的网管接口体系，做起来相对顺；E2是全新的接口，虽然E2AP协议和E2SM-RC/KPM等服务模型在联盟规范里已经冻结多个版本，但各家网元对E2SM的订阅支持度、测量粒度、控制命令覆盖面，公开资料里从来没有过一张完全对齐的清单。这直接决定了xApp能「看到什么、摸到什么」。 **第三层，控制权是敏感话题。** xApp通过E2下发的RAN控制命令，和设备商自己基带软件的内置逻辑，权力边界怎么划？切换是听xApp的还是听基带的？联盟规范给的是框架，落地全靠集成。这也是后面战报里纠纷最多的地方。 一张表对比两级应用： | 维度 | rApp（非实时） | xApp（近实时） | |---|---|---| | 部署位置 | SMO框架内 | 独立的近实时RIC平台 | | 控制环时延 | 1秒以上，到分钟/小时级 | 10毫秒～1秒 | | 上下游接口 | A1（下策略）、O1（管配置） | E2（控制+遥测）、A1（被管） | | 典型用例 | 模型训练、意图翻译、节能策略编排 | 实时切换优化、QoE预测干预、异常快速隔离 | | 数据来源 | 网管KPI、Tracing、外部数据 | E2订阅的MAC/RLC级实时测量 | | 成熟度 | 相对成熟，多家有商用案例 | 生态难点，生产网案例集中于少数玩家 | ## 三、愿景有多美：为什么大家曾为它激动 2018到2021那几年，RIC是通信圈最性感的词，没有之一。激动点无非三条： **一是反锁定。** 多厂商RAN环境下，运营商一直幻想「统一大脑」：不管基带是爱立信的还是华为的还是三星的，都通过标准E2接口接进我的RIC，我的AI在我的地盘上跑。议价逻辑很直白——你不想被我管？换一家。这也是DISH、乐天这类新玩家上头Open RAN的根本动机：新建网，何必背历史包袱。 **二是AI创新的「热插拔」。** 传统模式下，一个新算法从设备商立项到商用软件版本，两三年起步。RIC模式下，理论上一个学术团队的RL模型，打包成xApp就能上线灰度——不行就卸载，RAN不受损伤。开源侧也确实给了弹药：Linux基金会旗下O-RAN软件社区（[o-ran-sc.org](https://o-ran-sc.org/)）维护了整套参考RIC代码，EURECOM的FlexRIC做了轻量化实现，学术界基于这些平台发的论文数以百计（如OpenRAN Gym工作流基准，arXiv:2109.05083）。实验室里，故事是成立的。 **三是运维模式升级。** 我们这些老运维心知肚明：参数优化这活儿，靠人肉Excel核对的时代早该结束了。RIC承诺的是「平台+应用」的工业化模式——告警了上xApp查，节能了上xApp管，像手机装App一样给网络加能力。这个叙事在管理层的PPT里，就是「运维成本下降」的财务模型。 愿景没问题，问题出在落地这段路上。 ## 四、七年战报：谁真的在生产网上用起来了 冷静盘点公开信息，我把现状概括为三句话：**新玩家真用了，主流运营商在试点，设备商换了打法。** **第一，真正把RIC跑进生产网的，是两张「白纸网络」。** 乐天移动2020年4月商用全球第一张大规模云原生O-RAN网络，底层就带着RIC能力（来自其收购的Altiostar技术栈，后整合进Rakuten Symphony对外售卖）——它的模式很特殊：自研自用，xApp不对外开放生态，本质是把RIC当自家网元软件的内部插件架构。美国的DISH走的更激进，从零建O-RAN网络、公开宣传RIC开放生态，但几年折腾下来，据其公告与行业媒体报道，2023年起转向与AT&T的网络合作与批发模式，激进叙事明显降温。这两家的共同点是：**既是建设者又是设备商，RIC生态开放与否，自己说了算。** 这与「第三方App百花齐放」的原始愿景，已经是两回事。 **第二，主流大T的路径是「试点多、商用少、先软后硬」。** O-RAN联盟从2021年起每年组织全球PlugFest互操作测试，RIC与xApp的集成是历年必测项；欧洲多家运营商建了RIC实验室和试验网。但从公开渠道看，宣布「RIC+xApp规模商用承载现网业务」的主流运营商案例，至今屈指可数。行业里流传一个不算玩笑的观察：PlugFest上发现的问题，一大半出在xApp与网元的E2集成上——每个厂商的E2SM订阅能力、测量口径、控制命令覆盖都有细节差异，一个xApp在A厂网上跑通，到B厂网上重写一半是常态。（此处为本人一线经验判断与行业交流所得，非官方统计。） **第三，设备商的应对是「智能内嵌」+「换个联盟」。** 主流设备商的态度这些年看得很清楚：公开口径都是支持O-RAN开放架构，同时强调RAN智能应当内嵌在自家基带软件里，由自己负责闭环——毕竟切换、调度这些毫秒级决策的「责任田」，谁也不想让外人插手。2024年2月MWC期间，AI-RAN联盟（[ai-ran.org](https://www.ai-ran.org/)）宣布成立，NVIDIA、Arm、三星、软银、SKT、T-Mobile、爱立信、诺基亚等十四家为创始成员——注意这个名单：既包括激进派软银、NVIDIA，也包括此前对RIC态度微妙的爱立信、诺基亚。行业把注意力转向了「用GPU算力在基站上做AI」，软银的GPU基站已经另文写过。仔细品这个转向：**大家的共识没变——RAN要智能化；变的是「智能放在谁的进程里、用谁的平台」。** 一线运维最关心的其实是三个更土的问题，这里给出我的判断： 1. **KPI归因难。** xApp改了切换参数，掉线率降了0.1个百分点，这功劳算谁的？话务变了、天气变了、还是xApp的功劳？没有严格的A/B对照框架，AI应用的效果账永远是笔糊涂账，而这是采购决策的生命线。 2. **责任边界模糊。** xApp下发控制命令导致大面积掉线，责任在运营商、RIC平台商还是xApp开发商？故障定界链条里多了一个跨组织的环节，这对我们排障的人来说是噩梦级变化。 3. **安全暴露面扩大。** 多一层开放接口，多一类第三方代码，多一个供应链环节。RIC平台跑在通用服务器上，权限直通无线控制面，安全模型和传统专有设备完全不同。 这三条，才是xApp商店开张慢的真正原因——不是AI不行，是**商业与责任的重构比技术重构更慢**。 ## 五、路线之争：开放RIC、内嵌AI、AI-RAN 把2026年的牌桌摊开看，RAN智能化实际存在三条路线，各有各的地盘： | 维度 | 开放RIC路线 | 内嵌AI路线 | AI-RAN路线 | |---|---|---|---| | 核心主张 | 第三方xApp/rApp开放生态 | 智能内嵌基带，厂商闭环 | 基站算力平台化，AI通信业务一体 | | 代表玩家 | O-RAN SC、乐天、DISH（早期）、学术界 | 主流传统设备商 | NVIDIA、软银、AI-RAN联盟 | | 控制环位置 | 抽离到RIC平台 | 留在基带软件内 | 下沉到GPU算力底座 | | 开放度 | 最高 | 最低 | 中（硬件开放、平台封闭） | | 商用状态 | 少数自研自用案例 | 主流现网事实标准 | 试点到早期商用 | | 最大风险 | 生态碎片化、集成成本 | 锁定加深 | 算力成本与散热 | 我的判断是：**三条路线不会谁杀死谁，而是分层共存。** 内嵌AI继续承包毫秒级的「刚需智能」（调度、移动性、信道自适应）——这块责任大、门槛高，第三方短期内抢不动；开放RIC收缩到它真正擅长的地带：跨厂商的**策略层与编排层**（rApp生态、意图管理、模型训练下发），也就是非实时那一半；AI-RAN则在把基站变成「通信+边缘AI算力」的混合体，走的是加法而不是替换。O-RAN联盟规范体系本身也预留了这种多实现并存的空间，具体行为以各厂家官方文档为准。 对运营商来说，真正的战略问题只剩一个：**你愿意把哪一层的「控制权」留在自己手里？** 答案不同，采购的标书就完全不同。 ## 六、一线视角：现在能做什么、该学什么 最后说点实在的，给还在这行里干的兄弟三条建议： **第一，从rApp侧切入，别一上来就碰E2。** rApp本质是「网管侧的高级AI应用」，不碰实时控制，风险可控、不改变责任边界，用你现有KPI数据就能起步。把你手上的参数核查、扩容预测、节能编排做成rApp工作流，这是当前投入产出比最高的路径。 **第二，用开源平台把实验室搭起来。** O-RAN SC的全套参考实现和FlexRIC都是公开代码，一台服务器加软件无线电就能仿真一套CU/DU，把E2订阅、xApp生命周期管理这些概念亲手跑一遍。面试和投标的时候，「跑过RIC参考实现」和「看过架构白皮书」是两个段位。 **第三，技能栈往「双层」迁移。** 下层补E2SM、无线测量模型这些新协议词汇；上层补AI工程化的通用能力——数据集治理、A/B实验设计、模型版本管理。未来五年的无线优化岗，大概率是「懂RAN的AI工程师」而不是「会用AI的RAN工程师」——顺序很重要， 因为面试你的领导，问的第一个问题一定是：「你上个月那个优化，怎么证明是你的模型的功劳？」 ## 七、结语 七年前那张架构图上的箭头，如今大多已经画进了规范、跑通了PlugFest、甚至进了少数生产网。但「基站App商店」真正的瓶颈从来不是协议，而是商业：控制权、责任链、效果账本。这三座山搬完之前，xApp货架不会拥挤。而对一线工程师来说，这反而是好消息——生态混战期进入的人，才赶得上定义工作模式的机会。商店已开张，先去把操作系统玩明白。 ## 参考来源 1. [O-RAN Alliance 官方网站](https://www.o-ran.org/) — 联盟沿革、架构描述（WG1）、A1（WG2）、E2AP/E2SM（WG3）系列规范与全球PlugFest信息，本文架构解读主轴 2. [O-RAN Software Community](https://o-ran-sc.org/) — Linux基金会旗下开源RIC参考实现与xApp样例代码库 3. [AI-RAN Alliance](https://www.ai-ran.org/) — 2024年2月宣布成立，十四家创始成员名单与其AI-RAN技术主张 4. [Open RAN - Wikipedia](https://en.wikipedia.org/wiki/Open_RAN) — O-RAN联盟由xRAN论坛与C-RAN联盟合并而来的行业沿革背景 5. [OpenRAN Gym（arXiv:2109.05083）](https://arxiv.org/abs/2109.05083) — 基于O-RAN RIC的AI工作流开发与基准测试框架，学术界RIC生态的代表性工作 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。