本文约1900字，预计阅读时间6分钟。面向5G/6G工程师与技术决策者。

从工程实践角度看，将AI/ML模型塞进终端设备（UE）的基带芯片中，从来都不是一场纯粹的算法比拼。现实比论文残酷得多——一块手机芯片，既要跑AI推理，还要维持通话不断、导航不卡、电池不死。

无线通信标准的演进，本质上是在功耗、内存容量和信令开销之间寻找极限平衡的艺术。

在3GPP Release 19（Rel-19）中，AI/ML空口演进的聚光灯打在了单端模型（One-sided model）上，特别是基于UE侧的CSI预测（CSI Prediction）与波束管理。为了让这些模型真正在现网中跑起来，Rel-19确立了一套完整的生命周期管理（LCM）流程。这套流程看似按部就班，但如果深挖其协议细节，你会发现它处处充满了对物理极限的妥协，以及为未来Rel-20双端模型留下的伏笔。

UE物理约束如何倒逼数据收集机制？

在传统的算法研究中，获取训练数据往往被视为理所当然。但在真实的蜂窝网络里，让一部由电池供电的手机去执行L1层信道测量并记录海量数据，是一件危险的事情——不是安全意义上的危险，而是"用户下午就没电了"意义上的危险。

Rel-19 LCM的数据收集（Data Collection）环节，不仅规定了网络（gNB）如何配置UE进行测量，更核心的是引入了一套严密的缓存防御机制：当UE接入层（AS）的缓存达到阈值，或底层传感器检测到设备处于低电量状态时，协议赋予了UE主动拒绝数据上报的权限。

AI的地基，在手机里是会漏的。标准承认了一个现实：手机为了续航，会主动抛弃训练数据。

这意味着，我们在实验室里跑出的完美CSI预测模型，在现网部署时往往面临训练数据"碎片化"的困境。这不是算法的失败，是物理定律划下的底线。工程师们对此心知肚明，3GPP也只能顺势而为，在协议层面给UE留了一扇"自保"的门。

两种适用性报告的"历史包袱"

梳理Rel-19的适用性报告（Applicability Reporting）机制，是一件让人又爱又恨的事。3GPP给出了两套截然不同的信令框架并存——这不是标准设计失误，这是历史包袱和未来野心同台亮相的结果。每一个要落地实现的厂商工程师，都得为这两套逻辑各写一套解析代码，再花同等的时间去调试、验证、修Bug。

适用性报告是模型运行的"准入控制"节点，UE必须向网络报告其内置AI模型是否真正适用于当前的无线信道环境。为此，Rel-19给出了两条路径：

Option A：将AI适用性强行绑定在现有的物理层配置上（如CSI-ReportConfig），通过RRCReconfigurationComplete进行初始报告，再通过UE辅助信息（UAI）进行动态更新——最大程度复用现有RRC信令。

Option B：另起炉灶，绑定于OtherConfig或建立独立的推理参数集，预示着将AI模块化、独立化的野心。

Option A是传统通信厂商的惯性选择，它把AI仅仅视为"高级的CSI过滤器"。Option B则暗示着另一种未来：AI不再是信号处理的插件，而是一个独立的网络实体。

Rel-19的双轨制，短期是负担，长期是出口。在标准的世界里，保留冗余不总是坏事。

然而，这两种截然不同的解析逻辑必须同时在基站侧实现，这使得现阶段的网络实现变得异常繁琐——网络侧必须同时兼顾两种信令语法。这或许正是双轨制标准最真实的代价。

从 Associated ID 到 Pairing ID：打破单边黑盒

在探讨模型推理与性能监控之前，必须先审视Rel-19 LCM在模型身份识别上的一个核心局限。

Rel-19的模型身份识别高度依赖"关联ID（Associated ID）"——用一个ID将收集的数据集或训练好的模型，与网络侧的特定物理条件（特定天线面板配置、特定反射环境）硬绑定在一起。这套机制隐含了一个巨大的前提：

网络侧是一个绝对稳定的黑盒。只要Associated ID相同，协议就假设环境绝对一致。

这个假设在单站点、单厂商环境下逻辑自洽。但从工程实践的角度看，跨区切换、多供应商混合组网才是现网常态。一旦UE从爱立信基站切换到诺基亚基站，原来的Associated ID可能彻底失效。不解决跨厂商的模型对齐问题，AI在空口的增益就永远只能是单站点的孤岛——再好的算法，也走不出一个小区的边界。

这正是Rel-19被定义为单端模型"试水版"的根本原因：UE模型在适用状态下预测未来信道状态（克服信道老化延迟），向基站反馈预测后的CSI；网络检测到KPI（如信道预测误差）跌破阈值时，触发状态机回退（Fallback）到传统非AI机制。整个闭环，都局限于"UE单边努力，基站被动接收"的维度。

理论上，要彻底解决跨厂商和跨站点的模型对齐，就必须抛弃这种单边绑定的关联机制。这直接倒逼了Rel-20在处理更复杂的双端模型（基站和终端同时部署AI）时，果断弃用Associated ID，转而采用点对点的"配对ID（Pairing ID）"。

Rel-19靠关联，Rel-20靠握手。Pairing ID不再是单方面对环境的妥协，而是两端模型之间的一份双向通信契约。

镣铐的价值：探明边界，而非证明失败

Rel-19为单端AI模型建立的LCM流程，确实是一份扎实的工程基线。它规范了能力上报、数据收集、推理和回退机制，更重要的是，它用一套并不完美的Associated ID和双轨制信令框架，为我们探明了无线空口AI化的工程物理边界。

这套镣铐并非失败，而是诚实。 它坦率地承认了电池、芯片、信令的物理约束，而不是用一份漂亮的白皮书把它们掩盖起来。从这个意义上说，Rel-19的每一处妥协，都是一块勘探过的地基。

真正的考验在Rel-20。当基站和终端同时部署AI，当Pairing ID把两端的模型绑在同一份契约上，出错时该谁负责、该怎么回退、该如何跨厂商对齐——这些问题，Rel-19的工程基线并没有给出答案，只是留下了一个开口。

两端都有AI的空口里，谁来为这场握手的失败负责？

数据来源说明

本文技术描述基于3GPP TS 38.331、TS 38.214及TR 38.843（Rel-19 AI/ML空口技术报告）。关于Associated ID与Pairing ID的演进逻辑，参考3GPP RAN1[#116](javascript:😉-116b会议结论及RAN2架构讨论。