2018年2月，AT&T、中国移动、德国电信、Verizon几家运营商牵头成立O-RAN联盟，画了一张让整个行业热血沸腾的图：给基站装一个「操作系统」（RIC），第三方开发者在上面跑App（xApp/rApp），AI模型像换应用一样热插拔。七年过去，这场「基站App商店」运动到底开张了没有？谁在生产网上真用上了？本文以O-RAN联盟官方架构文档为主轴，结合开源社区与商用网络的公开进展，把RIC的两级控制环、E2接口的真实生态、三条技术路线的分野，从一线运维视角一次讲清楚。结论先行：商店开了，货架不算满，但操作系统本身正在换代。
干过无线优化的兄弟都懂一个痛：基站是个黑盒。网管上能看到的，是设备商嚼碎了喂给你的KPI——掉线率、切换成功率、PRB利用率，粒度15分钟起步，想拿毫秒级的MAC层原始数据？没有这回事。想在没有人工干预的情况下让算法实时改参数？更没有。
RIC（RAN Intelligent Controller，无线智能控制器）要解决的就是这个黑盒问题。按照O-RAN联盟的架构描述（WG1系列规范，可在官网下载），它把无线侧的智能化拆成了两级控制器，部署在SMO（Service Management and Orchestration，服务管理与编排）框架之下：
两者之间用A1接口传策略，RIC与无线网元之间，O1管配置、E2管实时控制与遥测。E2是整个体系的心脏——标准里定义了一组E2SM服务模型：E2SM-KPM管关键性能测量、E2SM-RC管无线控制、E2SM-CCC管小区配置，后来还陆续补了网络接口监测等。一句话总结这套设计：把原来焊死在设备商基带软件里的「智能」，抽出来变成可以第三方开发、按需加载的应用。
对干了十几年运维的人来说，这个抽象不难理解：RIC之于RAN，就像网元操作系统之于业务板卡。问题从来不在概念，在于生态。
很多人第一次看O-RAN架构图都会犯迷糊：为什么搞两个RIC？我用一张图把数据流和控制流捋直（架构细节以O-RAN联盟官方规范为准）：
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）维护了整套参考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）宣布成立，NVIDIA、Arm、三星、软银、SKT、T-Mobile、爱立信、诺基亚等十四家为创始成员——注意这个名单：既包括激进派软银、NVIDIA，也包括此前对RIC态度微妙的爱立信、诺基亚。行业把注意力转向了「用GPU算力在基站上做AI」，软银的GPU基站已经另文写过。仔细品这个转向：大家的共识没变——RAN要智能化；变的是「智能放在谁的进程里、用谁的平台」。
一线运维最关心的其实是三个更土的问题，这里给出我的判断：
这三条，才是xApp商店开张慢的真正原因——不是AI不行，是商业与责任的重构比技术重构更慢。
把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货架不会拥挤。而对一线工程师来说，这反而是好消息——生态混战期进入的人，才赶得上定义工作模式的机会。商店已开张，先去把操作系统玩明白。
本文由「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 等场景全覆盖。