——从OPPO提案看AI数据传输与LCM架构的统一之路

一个工程师要为同一份RSRP测量数据维护两套协议栈逻辑，仅仅因为它们分别服务于UE侧和网络侧的AI模型——这不是工程设计，这是对开发者的惩罚。在3GPP RAN2[#132会议的讨论语境下](javascript:😉，6G人工智能与机器学习（AI/ML）的标准化工作正从"概念发散"走向"架构收敛"。回顾5G Advanced的演进历程，一个略显尴尬的现象浮出水面：针对网络侧AI模型的数据收集，系统倾向于复用传统的MDT/SON框架（主要基于控制面CP）；而针对UE侧AI模型，讨论则更多转向用户面（UP）解决方案。这种人为的割裂设计，在6G时代是否应当继续延续？OPPO在其提交的文稿R2-2508043 "Discussion on data transfer and AIML"中给出了否定的回答。该提案不仅主张通过统一化的数据传输框架来消除UE实现的冗余复杂度，更在生命周期管理（LCM）的适用性报告机制上，提出了一种基于"奥卡姆剃刀"原则的极简方案——Option B。

一、数据传输：打破UE侧与网络侧的藩篱

在5GA的研究中，业界似乎形成了一种默契：网络侧AI任务偏向于"轻量级"或"慢速"的MDT机制，而UE侧AI任务则因涉及大量模型参数交互，需要"重量级"的UP通道。然而，这一逻辑存在根本性的漏洞。

1. 数据量级的非对称性迷思

并没有确凿的证据表明网络侧AI训练所需的数据量天生就比UE侧少。无论是用于波束管理（Beam Management）的网络侧模型，还是用于移动性优化的UE侧模型，其背后的数据需求在本质上相似——对于长期优化场景，单个服务的数据总量可能高达数百MB甚至TB级别。即便将任务分发给多个UE，单个UE需要上报的数据量也经常在数十KB至数百MB之间波动。如果6G标准继续沿用"因用途而异"的数据收集方案，后果是什么？同一类数据（如RSRP测量值），仅仅因为服务于不同侧的模型，就需要UE维护两套完全不同的协议栈逻辑。对于那些在前线与协议栈代码搏斗的工程师而言，这种设计带来的不是灵活性，而是无止境的冗余复杂度。

2. 统一框架的构建路径

R2-2508043提出了一个更为务实的演进路径：以终点定架构，而非以起点定架构。这句话值得稍作停顿来理解。传统思维是"数据从哪里产生，就用哪套协议"；而OPPO的提案则主张"数据被谁消费，才决定用哪套协议"。具体而言：场景一：数据终结于OAM。无论是SON、MDT还是QoE数据，只要最终消费者是OAM，且对延迟要求宽松，就应采用统一的传输设计。这在5G中已有部分基础，6G应将其标准化为通用管道。场景二：数据终结于RAN。对于直接服务于gNB的实时或近实时数据，应统一经由CP或UP上报至RAN，而不区分该数据是用于训练UE模型还是NW模型。

3. 对CP面瓶颈的辩证思考

这里存在一个技术争议：既然承认AI数据量可能很大，为何提案并未完全摒弃控制面（CP）方案？提案表现出了极强的工程现实感。虽然UP通道更适合大数据传输，但在6G早期或特定"小数据"场景下，CP方案（如RRC信令）依然具备成熟度高、建立连接快的优势。因此，统一框架并不意味着"唯UP论"，而是要在协议层面统一接口行为，对上层应用屏蔽底层的传输差异。高频操作不应为低频场景买单——这是贯穿整份提案的设计哲学。

二、LCM适用性报告：58368 bits的效率博弈

如果说数据传输关注的是"管道"的复用，那么生命周期管理（LCM）关注的则是"控制流"的精简。在AI模型的适用性报告（Applicability Reporting）机制上，OPPO对比了两种主流思路，并强烈推荐了更为激进的Option B。

Option A与Option B：两种设计哲学的碰撞

Option A（Full Inference Configuration）：UE基于完整的推理配置（如CSI-ReportConfig）来反馈该模型是否适用。这是传统RRC设计思维的延续——“给你全套配置，你告诉我能不能用”。Option B（Inference Related Parameters）：网络仅下发与推理直接相关的参数子集，UE基于此进行判断。直觉上，Option A似乎赋予了网络更大的灵活性。但它的代价是什么？

隐形成本的量化

R2-2508043给出了一个基于R18规范的极限计算：假设每个CSI-ReportConfig占用38 bits，在最大配置下（48个Report Config × 32个Serving Cell），Option A仅为了询问"能不能用"这一简单信息，就需要消耗最多58368 bits的空口资源。五万八千多比特，只为了一个"是"或"否"的答案。当然，58368 bits是理论极限值。在典型部署场景下（如4个载波聚合 × 8个Report Config），Option A的开销约为1216 bits。这个数字看起来似乎可以接受——但问题在于，随着6G载波聚合规模的扩大和AI模型复杂度的提升，“典型场景"正在快速向"极限场景"靠拢。更重要的是，无论实际使用多少配置，网络侧都必须为最大可能的配置预留资源，这才是Option A真正的隐形成本所在。更为严重的是资源预留问题。在Option A模式下，网络不知道UE会拒绝哪些配置，因此可能被迫为所有配置预留参考信号（RS）资源。一旦UE反馈"不适用”，这些预留的导频资源就成了纯粹的浪费。

灵活性与效率的权衡

反对者或许会质疑：Option B锁定了"推理相关参数"，如果未来模型对非推理参数（如QCL设定）敏感怎么办？这是一个典型的"灵活性悖论"。然而，从AI代理的高频交互特性来看，答案变得清晰：适用性检查通常发生在模型切换或环境微变的时刻，是一个高频操作。为了极少数可能需要调整基础参数的低频场景，而让每一次高频检查都背负沉重的信令包袱，显然不是明智之举。这里需要诚实地面对一个风险：如果Option B的参数子集不足以支撑准确判断，导致UE误报"适用"或"不适用"，怎么办？答案在于回退机制的设计。当UE基于子集参数判断"适用"后，实际推理过程中若发现性能异常，可以触发快速回退（Fallback）并请求完整配置验证。这种"先轻量判断、后按需补全"的策略，在绝大多数情况下能够避免全量信令开销，同时为边缘情况保留了安全阀。Option B通过仅传输关键参数，不仅降低了UE的解析复杂度，更将信令开销压缩到了极致。

三、性能监控：从辅助到自治的光谱

在数据与控制之外，R2-2508043还对性能监控（Performance Monitoring）的未来图景进行了描绘。对于UE侧模型，文稿并未试图给出一个"标准答案"，而是列举了从"保姆式"到"放养式"的5种演进场景。其中，Scenario 5格外引人注目：UE不仅自行监控性能，还自主做出切换或回退决策，无需向网络侧汇报。这预示了6G AI可能达到的自治水平——网络划边界，终端做决策。在当前的语境下，这或许显得激进。但如果我们面对的是数以亿计的AI终端管理难题，这种"策略边界 + 战术自主"的模式，可能是唯一可扩展的解法。当然，“自治"并不意味着"失控”。即便在Scenario 5中，网络侧仍然保留着关键的策略否决权：它可以通过下发策略边界参数（如允许切换的模型列表、性能阈值范围、最大切换频率等）来约束UE的决策空间。如果千万个UE的自主决策导致网络负载震荡（Ping-pong效应），网络侧可以通过收紧策略边界来恢复稳定。这种"宏观管控 + 微观自治"的分层架构，才是6G AI治理的真正内涵。

结论：效率与一致性，是协议设计的第一性原理

R2-2508043并非一份简单的技术罗列，而是一次对6G AI协议栈的"瘦身"与"重构"。它提醒我们，在追求AI赋能的同时，不能忽视通信协议设计最基本的原则。通过统一UE侧与网络侧的数据收集管道，我们可以结束5G时代的碎片化设计；通过采纳以参数子集为核心的Option B，我们可以消除数万比特的无效信令。对于正在参与6G标准制定的工程师们，这份提案或许值得反复阅读。它所倡导的"以终点定架构"和"高频操作不为低频买单"的设计哲学，不仅适用于AI数据传输，也可能成为6G协议栈设计的通用准则。在追求AI赋能时，效率与一致性才是协议设计的第一性原理。这种基于工程约束的理性回归，才是6G标准化工作最需要的底色。