**概述**：2026年2月26日，乐天移动与乐天Symphony宣布：对齐O-RAN标准的第三方rApp在乐天全国商用网上完成部署，官方称之为全球首例，并表示这项工作支撑了TM Forum L4自治网络验证。当网优工作从工程师手调参数，变成一群AI优化应用共享同一张无线网，一个躲不掉的新问题浮出水面：两个优化应用给出的指令打架了，听谁的？本文以乐天RIC全国部署为样本，结合arXiv上最新的冲突管理论文，拆解rApp/xApp冲突的三种类型、检测手段与仲裁机制，最后给一线运维几条能落地的建议。 ## 目录 - 一、乐天交了张「全球首卷」 - 二、先补课：rApp、xApp与那张控制网 - 三、打架的三种姿势：直撞、暗碰、影子坑 - 四、拉架的三种人：规则、图论与多智能体 - 五、为什么是乐天先干成 - 六、给运维人的四条实操建议 - 结语 - 参考来源 ## 一、乐天交了张「全球首卷」 先看官方口径。2026年2月26日，乐天移动与乐天Symphony发布新闻稿，宣布三件事：其一，乐天全国商用移动网上的RIC（RAN智能控制器）应用部署完成；其二，第三方rApp（来自AirHop Communications和Future Connections）已集成进非实时RIC环境；其三，这些应用支撑的用例包括预测性网络维护、移动性增强、流量优化和AI辅助决策。 乐天移动AI与数据监管部门总监Sachin Verma的表态很直白：第三方rApp全网铺开后，优化周期更快，网络更有韧性。AirHop工程副总裁Bijan Golkar则补了一句对开发者的价值——基于标准API的平台，把rApp「从需求到入网」的周期大幅压缩。 这里要替读者把「全球首例」四个字拆开看。新闻稿脚注写得清楚：这个「第一」限定在「基于Open RAN标准、端到端云原生、全国覆盖的4G/5G商用网上的RIC」，且是乐天自家的调研口径，截至2026年2月25日。换句话说，传统运营商不是没部署RIC和rApp，而是很少有人在一张全国级的纯Open RAN商用网上把它跑满。这个限定词本身就是行业现状的注脚——RIC说了这么多年，真正全国规模跑第三方应用的 commercially live 网络，一只手数得过来。 还有一条容易被忽略的信息：新闻稿明确说，这项工作「对TM Forum自治网络L4验证做出了重大贡献」。也就是说，乐天把rApp冲突治理、闭环自动化这些能力，打包交了L4的卷。这条线索正是本文真正的主题：**闭环一多，闭环之间会打架**。 这件事不是突发的。把时间线拉出来看，乐天这张RIC网是四年攒出来的： | 时间 | 事件 | 来源 | | --- | --- | --- | | 2023-02 | 获日本NICT委托研发，启动面向Beyond 5G的RIC研究 | 乐天官方新闻稿附注 | | 2024-02 | MWC期间，zTouch Networks宣布AI rApp/xApp接入乐天SMO与RIC平台 | zTouch官网 | | 2024-10 | arXiv:2411.03326提出xApp冲突分类与冲突图分析框架 | arXiv | | 2025-03 | Aether（Linux基金会项目）与乐天启动节能、流量引导类rApp试验 | Aether新闻稿 | | 2025-05 | 自研RIC在乐天全国4G/5G商用网部署 | 乐天官方新闻稿 | | 2026-02 | 第三方rApp全国部署完成，官方称支撑TM Forum L4验证 | 乐天官方新闻稿 | | 2026-03 | 多智能体rApp冲突感知编排论文上线arXiv | arXiv | ## 二、先补课：rApp、xApp与那张控制网 要看懂「打架」，得先看清控制权的分层。O-RAN把无线网的大脑拆成了两层： - **非实时RIC（Non-RT RIC）**：挂在SMO框架下，运行rApp。它的控制周期在秒级以上，产出的是**策略和意图**，通过A1接口下发给下层。比如「把低话务小区在凌晨休眠以省电」是一条策略，而不是一条具体的参数指令。 - **近实时RIC（near-RT RIC）**：运行xApp，控制周期在10毫秒到1秒之间，通过E2接口直接操控基站。rApp的策略到了这里，被翻译成具体的切换门限、功率、邻区参数改动并执行。 用一句话概括：**rApp动嘴，xApp动手，基站干活**。传统网优则是另一幅图景——集中式网优工具出报告，工程师评估后手工改参数，一切冲突在人的脑子里被消化掉。rApp/xApp架构把「消化冲突」这个环节交给了机器，但机器之间的消化器官，行业还没有公认的成品。 | 维度 | rApp（非实时RIC） | xApp（近实时RIC） | 传统集中式网优 | | --- | --- | --- | --- | | 所在位置 | SMO框架内 | 近实时RIC内 | 独立OSS工具 | | 控制周期 | 秒级以上 | 10毫秒至1秒 | 天/周级 | | 控制方式 | 策略与意图（A1接口） | 直接参数控制（E2接口） | 人工审批改参 | | 典型用例 | 节能、容量预测、移动性策略 | 切换优化、干扰协调、快速节能 | 例行参数审计 | | 冲突风险 | 策略间目标冲突 | 执行面指令相撞 | 靠人工把关 | 画成图，闭环是这样的： ```mermaid flowchart TD U["运营商意图"] --> NRC["非实时RIC"] NRC --> RC["冲突协调"] RC --> R1["rApp：节能"] RC --> R2["rApp：移动性"] R1 -->|A1策略| X1["xApp：关小区"] R2 -->|A1策略| X2["xApp：调切换"] X1 -->|E2控制| BS["基站"] X2 -->|E2控制| BS BS -->|KPI回传| NRC NRC -->|劣化时| H["人工兜底"] ``` 问题就出在这张图的每一条箭头上：多个rApp可以同时合法存在，多个xApp可以同时盯住同一个基站的同一组参数。**各自都对，合起来出事**——这是自动化网络特有的病。 ## 三、打架的三种姿势：直撞、暗碰、影子坑 冲突到底长什么样？爱尔兰都柏林大学学院团队的Wadud、Golpayegani和Afraz在arXiv论文（编号2411.03326，2024年10月提交、2025年2月修订）里给了一个系统的分类框架，把xApp层冲突分成三类。这个分类现在被后续研究广泛沿用，值得一线工程师记住。 **第一类：直撞（直接冲突）。** 两个应用在同一时刻、对同一组控制参数下达了相互矛盾的指令。节能xApp要求某小区凌晨一点休眠，移动性xApp却要求同时调整该小区的切换参数——休眠状态下参数写入可能直接失败，或者写入后被覆盖。这是最容易理解、也最容易检测的一类，因为参数重叠是显性的。 **第二类：暗碰（间接冲突）。** 两个动作在时间或参数上都错开了，单看每一次改动都合规，但它们的**终态相互顶牛**。节能应用把小区A休眠，把话务推给小区B；移动性优化应用随后发现小区B过载，把切换门限调低想让话务回流——话务在两个小区之间来回震荡，KPI同步劣化。暗碰的麻烦在于，冲突不在任何一次单独的动作里，而在两次动作的**组合效应**里。 **第三类：影子坑（隐式冲突）。** 某个动作当场看完全无害，但它触发的连锁反应在一段时间后引爆冲突。这篇论文用移动性驱动节能做了实验场景：移动性鲁棒性优化（MRO）xApp与节能（ES）xApp同场运行，节能侧的休眠决策改变了几何后的邻区关系，移动性侧基于旧邻区数据做出的调整反而放大了切换失败。等KPI曲线掉头向下，工程师回溯信令，很难一眼看出第一块多米诺骨牌是哪张。 | 冲突类型 | 触发机理 | 典型场景 | 为何难发现 | 主要对策 | | --- | --- | --- | --- | --- | | 直接冲突 | 同参数同时被相反指令写入 | 节能休眠 vs 移动性改参 | 低，参数重叠显性 | 参数覆盖登记、互斥锁 | | 间接冲突 | 时间或参数错开但终态互抵 | 话务搬家 vs 门限回调 | 中，需看组合效应 | 策略级联仿真、冲突图 | | 隐式冲突 | 单个动作无害，连锁后引爆 | 休眠改变邻区拓扑 | 高，因果链长且滞后 | KPI劣化回溯、AI检测 | 论文的分析工具是**冲突图**：把每个控制动作当成节点，把「会打架」画成节点之间的边，冲突治理就从运维问题变成了图论问题——找出能同时执行的最大动作集合，本质上接近图着色。检测手段上，作者用SLA和QoS门限做哨兵：KPI一旦越过门限，反查冲突图里当前活跃的边。评估环节，作者在仿真环境里让MRO和ES两个xApp真刀真枪打了几轮，比较了多种缓解策略的效果。这些结论来自仿真而非现网，但分类框架对现网排障已经够用。 ```mermaid flowchart TD C["xApp冲突三兄弟"] --> D["直撞
同参数相反指令"] C --> I["暗碰
错时错参却顶牛"] C --> M["影子坑
当时无害
连锁后爆雷"] ``` ## 四、拉架的三种人：规则、图论与多智能体 冲突既然必然发生，谁来拉架？业界目前是三代思路同场竞技。 **第一代：规则派。** 给每个rApp或xApp定优先级，冲突时高优先级说了算；再维护一张冲突矩阵，声明哪些用例不能同时开启。这是眼下商用部署的主流做法，简单可靠。短板也明显：优先级是静态的，凌晨低话务时段节能该优先，晚高峰 obviously 该轮到容量和移动性，静态规则应对不了动态场景。需要说明，O-RAN标准在架构层面为冲突协调留了位置，但具体用什么机制实现，标准允许多种做法，以各厂家官方文档为准。 **第二代：图论派。** 就是上一节的冲突图路线，把冲突治理做成算法问题。这条线上2026年还在出成果：加州大学圣迭戈分校团队的ORCA框架（发表在INFOCOM 2026）专门处理「没见过的、动态环境里」的xApp资源冲突检测与缓解——堵的是规则派和静态冲突矩阵最怕的盲区：新应用入网、场景漂移之后，老冲突表失效。 **第三代：多智能体派。** 2026年3月上线arXiv的论文（编号2603.07375，已被IEEE收录）走得更远：它指出当前rApp开发「仍以手工为主、脆弱且难扩展」，提出用多智能体AI把运营商的高层意图自动翻译成rApp策略，再编排成一串xApp流水线，并在编排阶段就做冲突感知。同一时期，Elsevier《Computer Networks》2026年8月刊的论文系统论述了用AI做Open RAN冲突的实时检测、分类与缓解，结论是：随着xApp数量、控制参数和KPI维度膨胀，传统基于规则的冲突管理越来越不可行，AI驱动方案成为必需。 三代不是替代关系，更像叠加关系：规则做底线护栏，图论做事前推演，AI做动态检测与仲裁。乐天2026年2月的新闻稿里「冲突缓解、智能编排」这些措辞，配合其「多rApp规模化部署」的技术博客，可以判断其平台上已经落地了工程化的协调层——具体实现细节属厂家内部，官方口径止步于此。 ## 五、为什么是乐天先干成 这事轮到乐天先交卷，不是偶然，四个条件缺一不可。 **第一，网是自家的「白纸」。** 乐天2020年起用Open RAN建全国网，基站、RIC、编排全跑在云原生架构上，没有历史厂家的私有接口包袱。第三方rApp要接入，把标准API对接一遍就行；传统运营商的现网里，光是把各厂家基站的管理接口归拢到SMO下面，就是以年为单位的工程。 **第二，规模刚好够用又可控。** 全国一张网、单一市场、单一生态，出问题影响面在一个国家内部，灰度与回滚的腾挪空间大。传统跨国运营商动一处参数要过十个国家的合规审查，闭环自动化天然跑不快。 **第三，平台是自研的。** 乐天Symphony的SMO/RIC平台既是自家现网的生产系统，又是对外销售的产品——现网先吃自己的狗粮，问题在自己手里暴露，迭代周期比「甲方乙方」模式短一个量级。 **第四，政策与研发的长期输血。** 从2023年2月起，日本NICT就以委托研究和资助两种方式持续投入RIC与边缘云研发，新闻稿里两个编号的科研经费注脚说明了这不是纯商业冒险，而是国家预算托底的长期工程。 对传统运营商，乐天这份卷子的参考价值要打折扣地看：它是单一厂家生态、单一市场、轻负载起步网络的特例。但它验证了两件事——第三方rApp在全国级商用网上的**工程可行性**，以及**冲突治理是闭环自动化的前置条件**而非可选项。这两点对所有路径的运营商都成立。 ## 六、给运维人的四条实操建议 就算你所在的网络还没上RIC，冲突治理的思路现在就能用。 **第一，先建「参数覆盖登记册」。** 把所有自动化功能（厂家SON、自研脚本、第三方工具）各自能碰哪些参数列成一张总表，任何两个功能出现交集，就是潜在冲突点。这张表是后面一切治理的地基，也是审计时的铁证。 **第二，把回退机制做成默认项。** 任何自动化动作入网前，先明确它的回退触发条件、回退参数快照和回退执行人。影子坑类冲突的最后防线就是可靠的回退——不是防住第一块骨牌，而是让骨牌倒到第二块就停。 **第三，用时间窗隔离天然对撞的用例。** 节能与容量/移动性优化是教科书级的冲突对，与其指望仲裁算法，不如先在时间轴上错峰：闲时开节能闭环，忙时强制节能退避并让位给容量闭环。规则很笨，但在仲裁机制成熟之前，笨办法最保命。 **第四，KPI哨兵要盯「组合指标」。** 单看切换成功率、单看耗电量都发现不了暗碰，要把「切换成功率+单耗电量+话务分布」组合起来设门限，任何一个指标的异常改善伴随另一个的异常劣化，就触发回溯。这正是arXiv那篇论文用SLA/QoS门限做冲突检测的工程翻译。 ## 结语 无线网优正在从「人对参数」变成「策略对策略」。乐天把第三方rApp铺满全国商用网，证明的是开放架构的工程可行性；而arXiv上一批冲突管理论文刷存在感，证明的是这套架构真正的软肋——闭环一多，闭环之间会打架。谁先把拉架机制做成产品，谁的自治网络L4才不是修辞。对一线运维，这件事的启示朴素得很：自动化的下半场，比的不是谁跑得快，而是谁打架打得少、打得赢的时候知道什么时候收手。 ## 参考来源 1. [Rakuten Mobile and Rakuten Symphony Advance Open RAN Innovation with Third-Party rApp Integration and Nationwide RIC Deployment](https://corp.mobile.rakuten.co.jp/english/news/press/2026/0226_01/) — 乐天官方新闻稿（2026-02-26），全国RIC部署与第三方rApp集成的一手口径 2. [Rakuten Mobile and Rakuten Symphony Deploy Intelligent AI-powered RIC](https://corp.mobile.rakuten.co.jp/english/news/press/2025/0528_01/) — 乐天官方新闻稿（2025-05-28），自研RIC全国4G/5G商用网部署 3. [xApp-Level Conflict Mitigation in O-RAN, a Mobility Driven Energy Saving Case](https://arxiv.org/abs/2411.03326) — arXiv:2411.03326，冲突三分类、冲突图与MRO/ES仿真评估 4. [Multi-Agentic AI for Conflict-Aware rApp Policy Orchestration in Open RAN](https://arxiv.org/html/2603.07375v1) — arXiv:2603.07375，多智能体rApp策略自动生成与冲突感知编排 5. [Open RAN Conflict Agents (ORCA): Detecting and Mitigating xApp Conflicts](https://xyzhang.ucsd.edu/papers/DC.Kwon_INFOCOM26_ORCA.pdf) — INFOCOM 2026，UCSD团队的动态环境xApp冲突检测与缓解框架 6. [Aether, Rakuten Mobile, and Rakuten Symphony Collaborate on Energy Savings and Traffic Steering rApps](https://aetherproject.org/press-release/2025/03/aether-rakuten-mobile-and-rakuten-symphony-collaborate-to-address-key-energy-savings-and-traffic-steering-challenges-for-heterogeneous-mobile-networks/) — Linux基金会Aether项目新闻稿（2025-03-12），节能与流量引导rApp联合试验 --- > 本文由「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 等场景全覆盖。