# 拆解Rel-19 AI空口：UE侧推理落地，CSI压缩为何消失 **概述**：R18研究了三年的“AI空口”，在Rel-19终于转成了规范条文。但真打开TS 38.331逐条数，你会发现实际交付的和会场海报上的不是一回事：UE侧波束预测（空间域、时间域）、CSI预测、数据采集与模型监测进了标准；而业界宣传最多、论文最多的CSI压缩双端模型，在RRC信令里一条都没有。本文基于TS 38.331 Rel-19的27个`aiml-*`信令标识符逐项拆解：AI推理如何占用UE的CSI处理预算、0.5~4毫秒的推理时限如何在6种子载波间隔下保持不变、以及网优工程师面对厂商“支持3GPP AI/ML”话术时该问哪五个问题。 --- ## 一、一个没人正面回答的问题 “AI到底进标准了没有？”这个问题，过去一年在AT&T、DT、NTT DOCOMO的联合立项文件里出现过，在设备商的RFP应答表里出现过，也在无数RAN内部培训的答疑环节里出现过。得到的回答通常是两种：一是“AI原生RAN，六G的核心”（画饼式），二是“3GPP已经在Rel-18/19开展了AI/ML研究”（和稀泥式）。 标准的事实比这两种回答都有意思。Rel-18是RAN1主导的研究项目（SI），产出是TR 38.843——评估了CSI反馈、波束管理、定位三大场景AI化的收益、复杂度与规范化影响。Rel-19将其中的选定结论转成了规范性工作项NR_AIML_air（WI #1020093）及其核心部分NR_AIML_air-Core（WI #1021093），据arXiv上2026年8月一篇关于AI/ML生命周期管理的论文梳理，Rel-19的规范化范围覆盖了AI/ML辅助的CSI预测、波束管理和定位，加上配套的数据收集、适用性评估与性能监测机制。 关键在于交付的**形状**。有开发者逐条检索了Rel-19版TS 38.331（NR RRC协议规范），大小写不敏感匹配`aiml-`前缀，去重后得到**27个标识符**。其中CSI压缩（编码器在UE、译码器在gNB的双端模型）的信令数量是**零**。这不是“还没讨论完”，这是一个明确的架构决策。而真正写进信令的内容，比营销材料上的“AI-native”要具体得多，也谦逊得多。 ## 二、五字段的“AI框架”：标准没碰模型本身 一切从UE能力信令里的`AIML-Parameters-r19`开始。猜猜这个号称“AI框架核心”的信息元里有什么？ ``` AIML-Parameters-r19 ::= SEQUENCE { applicabilityReportingCSI-r19 ENUMERATED {supported} OPTIONAL, applicabilityReportingOther-r19 ENUMERATED {supported} OPTIONAL, loggedDataCollection-r19 ENUMERATED {supported} OPTIONAL, eventBasedLoggedDataCollection-r19 ENUMERATED {supported} OPTIONAL, dataThresholdAvailabilityIndication-r19 ENUMERATED {supported} OPTIONAL } ``` 五个字段，全部可选，全部是不带任何参数的"supported"开关。两个是适用性上报（UE告诉网络它的模型在什么条件下有效），两个是数据收集（一个普通、一个事件触发），一个是数据量阈值到达指示。**没有一个字段描述模型**——没有层数、没有结构、没有权重格式、没有模型ID、没有版本号。 这个设计初看令人失望，细想是对的。模型每18个月迭代一代，而规范一旦冻结就要在硅片里活十年。如果Rel-19把某个2024年水平的自编码器拓扑写死，2026年之后卖出的每一台终端都得背着它走到2035年。标准真正该固化的是必须公共的部分：描述模型适用范围的词汇、把训练数据从终端搬回网络 (offload) 的机制、模型输出的报告格式。模型本身留给厂商竞争。 对运营商的启示很直接：下次厂商说“我们的产品符合3GPP Rel-19 AI/ML”，诚实的翻译是“我们的UE置位了`loggedDataCollection-r19`”——这是一个数据收集能力声明，对模型好不好、能不能与别家互通，**什么都没说**。 ## 三、BM-Case1：测4根波束，报64根的经济账 毫米波小区没有“覆盖区”，只有一扇窄波束组成的风扇。找对波束靠测量：64个候选波束，每个都发参考信号、每个都测、每个都上报——每轮扫描如此，永远如此。参考信号开销是真金白银的频谱，而且越加波束越亏：为了提高增益加波束，结果自己的容量烧在了“找哪根波束”上。 AI方案简单得近乎粗暴：测几根，推其余。3GPP把小测量集叫**Set B**，全候选集叫**Set A**。这就是BM-Case1（空间域波束预测），也是少数真正进了信令的AI特性： ``` aiml-BM-Case1-r19 SEQUENCE { maxNumberOfResourceSetB-r19 ENUMERATED {n4,n8,n16}, -- 实际测量的波束 maxNumberOfResourceSetA-r19 ENUMERATED {n8,n16,n32,n64}, -- 出答案的波束 subUseCases-r19 ENUMERATED {subset, diffSet, both}, maxNumberOfPredictedBeamPerReportingInstance-r19 INTEGER (1..4), numberOfOccupiedCPU-r19 INTEGER (0..8), ... } ``` 取两个极值算账：Set B=4、Set A=64，即只测量6.25%的波束空间，推断其余93.75%。测量开销直接砍掉一个数量级，这就是它进标准的理由。 三个值得展开的细节： **其一，`subUseCases`是被低估的字段。**`subset`模式下Set B是Set A的子集——测64根真波束里的8根，推其余56根；`diffSet`模式下Set B**不是**子集，这打开了另一扇门：测几根宽波束，预测一堆窄波束，测量侧和预测侧可以是完全不同的天线配置。一个UE支持前者不代表支持后者，采购验收时要分别确认。 **其二，风险藏在测量侧。**从Set A=32扩到64是“免费”翻倍（只是外推得更远）；从Set B=8缩到4是直接劣化模型输入。两者都拉低精度，但只有前者在你的PM计数器里不可见——收缩测量集带来的波束失败，运维很容易归因到无线环境。 **其三，失败签名与经典扫波束完全同形。**经典扫波束出错，是因为无线环境变了，测量“诚实地过期”了；AI预测出错，是测量没错但**推断**错了。这两种失败在网管计数器上产生完全相同的KPI签名——都是波束失败恢复事件。除非监测体系专门设计过区分手段（这正是`aiml-BM-Monitoring-r19`存在的理由，见第七节），否则你分不清自己面对的是哪一种。 ## 四、BM-Case2：1.28秒的预言 BM-Case1在空间上外推，BM-Case2在时间上外推——UE拿一段波束测量历史，上报未来时刻的最优波束。这是标准第一次正式为“预测未来”立规矩： ``` aiml-BM-Case2-r19 SEQUENCE { minNumberOfKBM-SetB-r19 ENUMERATED {n2,n4,n8}, -- 历史输入个数 maxNumberOfPredictedTimeInstance-r19 ENUMERATED {n1,n2,n4,n8}, -- 预测几个未来时刻 timeGap-r19 ENUMERATED {ms10,ms20,ms40,ms80,ms160}, maxTotalNumberOfPredictedBeamPerReport-r19 ENUMERATED {n1,n2,n4,n6,n8,n12,n16,n32} } ``` 四个字段定义预测视野：8个未来时刻 × 160ms间隔 = **1.28秒**。规范里没有印出这个总视野数字——这是参数极值的乘法，但这笔算术没有争议。90 km/h的车速下，1.28秒是32米；在毫米波街道峡谷里，32米就是“看得见基站”和“被大楼挡死”的距离。 有意思的是报告上限的 craftsmanship：每时刻4波束 × 8时刻 = 32，恰好等于`maxTotalNumberOfPredictedBeamPerReport-r19`的最大合法值32。不多不少。这说明RAN1里有人按极值场景整体 sizing 过这套参数，而不是各参数独立讨价还价的结果。 而真正的优化难题在**配置**：没有任何规范条文告诉你`timeGap`该选多少。8×160ms视野长但分辨率粗——你知道1.28秒后波束在哪，不知道400ms时发生什么；8×10ms分辨率精细但总视野只有80ms——对行人近乎无用，因为80ms内什么都不会变。`timeGap`要匹配的是小区的**移动性分布**，而移动性不是一个常数，是一个分布。选慢了预测过期，选快了烧上行开销去预测一个没变化的未来。这是标准的参数整定问题——换句话说，是网优用电子表格和悔恨解决了二十年的那类问题。AI没有消灭它，只是给它换了个参数名。 ## 五、CSI预测与N4问题：标准用切分告诉你哪个更难 比波束预测更安静、但可能更重要的，是CSI预测。问题叫**信道老化**：UE测量信道、算出CSI、上报，等gNB按这份CSI调度时，信道已经变了。3.5 GHz载波、100 km/h下，信道在几毫秒内去相关——预编码器瞄准的是信道的“过去”。经典解法是加密上报，代价是上行开销；AI解法是上报信道**在传输时刻将变成的样子**。 CSI预测能力被切成了四条独立条目，切分点是一个叫**N4**的参数——测量窗内CSI-RS资源的个数，即预测器能看到多少张信道快照： - **R1 58-3-1**：N4=1时的UE侧推理CSI预测； - **R1 58-3-2**：N4>1时的UE侧推理CSI预测； - **R1 58-3-4**：UE侧CSI预测数据收集； - **R1 58-3-5**：CSI预测模型性能监测。 这个切分不是官僚主义。N4=1意味着只有一张快照、没有可观测的多普勒，任何“预测”本质上都是关于信道行为规律的先验；N4>1才有时序可用，才谈得上时序模型。这是两种硅片需求、两种内存占用。切开来，便宜的终端可以只支持简单场景而不必对难的撒谎。 还有一个容易被漏掉的保守设计：CSI预测的`inferenceReportType-r19`里，只有非周期和半持续，**没有周期**。对比BM-Case1三种报告类型齐全——AI预测的CSI不允许被配成一条无人值守的周期性报告流，网络必须显式触发或激活。网络始终把手指按在开关上。 ## 六、推理不免费：CPU预算与4毫秒铁律 这是整套设计里最精巧、却最少被讲透的部分。 5G UE有一笔**CSI处理单元（CSI Processing Unit, CPU）预算**——注意这里的CPU不是通用处理器，是信道状态信息处理容量的计量单位。网络每要求UE算一份CSI报告，该报告就占用一个或多个CPU一段时间；并发请求超出预算时，UE**有权拒绝计算**其中一些。这是一个真实的、调度器必须尊重的硬约束。 Rel-19让AI推理**付进同一本账**：每个AI特性都带着`numberOfOccupiedCPU-r19 INTEGER (0..8)`和`occupiedResourcePool-r19 INTEGER (1..2)`。 先看下界——**零**。UE可以声明它的AI推理不占用任何CSI处理单元。规范不要求AI有任何可计量的成本。这是漏洞吗？换个角度想：如果一颗终端芯片有独立的神经加速器，波束预测器跑在与CSI处理路径完全隔离的硬件上，那“零”就是诚实的回答——强迫它虚报成本反而让调度器对设备的建模更不准。但它同时意味着：**CPU占用字段是规范背书的、让两颗天差地别的芯片在纸面上长得一模一样的方式**。一颗声明0是因为真有NPU，另一颗声明0是因为过于乐观。规范分不出，采购清单也分不出，只有实验室分得出。写测试用例的同行记一条：“推理占用pool 2时，pool 1的普通CSI报告是否受影响”——Rel-18引入多CPU池、Rel-19让AI声明用哪个池，这套隔离设计就是给这种测试留的口子。 再看推理时限。每个AI特性都带一组`relaxationTimeline`字段，按子载波间隔以**符号数**给出UE的额外计算时间。六种numerology，符号数从n7一路到n1792，看起来像六架不相关的梯子。但换算成真实时间——一个常规CP的OFDM符号持续1/(14·2^μ)毫秒——所有梯子在毫秒轴上**坍缩成同一架**：0.5、1.0、1.5、2.0、2.5、3.0、4.0毫秒。15 kHz如此，960 kHz也如此。推理时延是硅片的属性，不随子载波间隔变快，所以预算必须是绝对时间，规范只是用物理层唯一认识的语言（符号）把它写出来。 两处细节暴露了标准的态度。一是**3.5 ms档位缺失**：BM-Case1的梯子从3.0直接跳到4.0，模型需要3.4ms就只能报4.0，每次报告永久浪费0.6ms。二是**难度分级**：波束空间预测给到4ms，波束时间预测（BM-Case2）给到7ms，信道矩阵预测（CSI预测）给到8ms且梯子改为倍增而非步进——倍增是“不知道实现需要多少”时的写法。标准用它唯一会的方式告诉你：哪个问题最难。 ## 七、最大的狗没有叫：CSI压缩为何出局 最后说缺席，因为在规范里，缺席就是决策。 五年来AI空口的旗舰创意一直是CSI压缩双端模型：编码器在UE把信道估计压进几十个比特，译码器在gNB重建。文献里的增益数字很大，想法很优雅，它是人们说“AI原生空口”时心里想的东西。**它不在Rel-19的RRC规范里。**不是能力项、不是配置项、不是报告类型——检索计数为零。 对比一下两边： | 维度 | 业界在谈的（未入标准） | Rel-19实际交付的 | |---|---|---| | 模型架构 | CSI压缩自编码器 | UE侧单边模型 | | 双端配对 | 编码器/译码器分驻UE与gNB | 模型整体驻留UE | | 模型传输 | 空口下发模型、模型ID协商 | 无任何模型下发机制 | | 联合训练 | UE与gNB联合训练 | 厂商私有训练，网络不参与 | | — | — | 空间波束预测（BM-Case1） | | — | — | 时间波束预测（BM-Case2） | | — | — | CSI预测（N4=1 / N4>1两档） | | — | — | 性能监测 + 数据采集 + 适用性上报 | 右边每一项都是**单边的**：模型在UE里，消费UE本来就要做的测量，产出网络本来就认识的报告格式。模型再烂，产出的仍是合法报告，只是精度差些——网络甚至不需要知道模型存在。而双端模型要求我的编码器和你的译码器共同训练或至少对齐到一个共享的潜空间——一个没有物理含义、任何一方都无法独立验证的学到的表示。对不齐时，译码器输出的不是“略差的信道估计”，而是**噪声**。单边模型失败产生坏报告，双端模型失败产生一份“语义被偷换”的报告——这是两个不同级别的风险。 再往下是商业问题：要让双端模型互通，要么标准化模型本身（把2024年的架构冻进十年的硬件），要么建立把一家厂商的训练模型送进另一家厂商设备的机制——权重归谁、出错谁负责、再训练谁买单、怎么验收一个“尚不存在的模型”，没有一条是无线工程问题，条条都是硬骨头。 所以Rel-19交付了可工程化的子集。我的判断是这个选择是对的——四个能跑的特性，好过一个架构学争论。但它意味着：当厂商宣称“3GPP Rel-19 AI/ML空口”时，诚实的翻译是**UE侧波束预测、UE侧CSI预测，以及支撑它们的数据收集**。这是真实有用的东西，只是不是会议海报上那个东西。 ## 八、生命周期闭环：标准怎么防模型翻车 学术论文报告测试集精度，规范必须回答“它失灵了怎么办”。Rel-19的答案有自己的特性组编号（R1 58-1-6）： ``` aiml-BM-Monitoring-r19 SEQUENCE { maxNumTotalResource-r19 ENUMERATED {n4,n8,n16,n32,n64}, monitoringResourceType-r19 ENUMERATED {periodic, semipersistent}, monitoringReportType-r19 ENUMERATED {periodic, aperiodic, semipersistent}, maxNumOccasion-r19 ENUMERATED {n1,n3,n7,n15}, ... } ``` 网络可以专门分配最多64个监测资源，让UE**真刀真枪测量**一部分模型声称预测了的波束，然后与预测对账——监测报告显式关联到它所评估的预测配置，按预测时刻给出精度指示（据nextgcomm对Rel-19特性的拆解，波束预测与CSI预测均支持）。`maxNumOccasion`的取值n1/n3/n7/n15全是2^k−1，一看就是给比特掩码编码留的——写标准的人在想着空口的比特，不是在想着机器学习。 配上数据收集（58-1-7波束、58-3-4 CSI预测）和适用性上报，完整的生命周期闭环是：**采集 → 厂商私有训练 → 适用性声明 → 推理 → 监测对账 → 触发再训练**。注意`subCase-r19`的三个取值`equal/subset/notSubset`——训练数据的采集几何与推理时的Set B/Set A关系可以对齐，这是把“训练/服务偏斜”（train/serve skew）这个机器学习的经典坑，直接用枚举值固化进了规范。 ```mermaid flowchart TD A[UE侧数据采集
58-1-7 / 58-3-4
logged / eventBased] --> B[厂商私有训练
规范之外] B --> C[UE能力上报
AIML-Parameters-r19
适用性声明] C --> D{网络配置推理} D --> E[BM-Case1 空间预测
Set B 4~16 → Set A 8~64] D --> F[BM-Case2 时间预测
K个历史 → 未来10~160ms×N] D --> G[CSI预测
N4=1 / N4>1] E --> H[推理占用CPU预算 0~8
时限0.5~8ms绝对时间] F --> H G --> H H --> I[监测对账 58-1-6/58-3-5
预测 vs 实测] I -->|模型漂移| A I -->|精度达标| J[持续服务
报告格式与经典CSI兼容] ``` ## 九、商用进展：标准之内刚冻结，标准之外已抢跑 规范 freeze 与现网抢跑是两条平行线。一方面，Rel-19的AI空口信令2025年才陆续冻结，UE侧生态（芯片、终端、IDA互通测试）还在爬坡，真正的规模商用窗口在2026~2027年。 另一方面，**不走3GPP空口信令的AI RAN优化已经在现网出成绩单**。据7g.network 2026年5月的AI-RAN基准报告，DT柏林试验网运行诺基亚AirFrame AI方案取得11%吞吐提升与25%节能——该报告同时点出代价：与AirScale生态的深度绑定。诺基亚在2026年MWC前的分析师会上（据Data Center Dynamics报道）强调了与英伟达合作的进展；爱立信则把Rel-19的AI/ML框架称为“AI集成的骨干”（据RCR Wireless）。注意区别：这些网络侧AI（gNB内模型、RIC xApp）不依赖Rel-19的UE侧信令，今天就能部署；而Rel-19标准化的UE侧推理，要等终端存量换过一轮才见真收益。 | 特性 | BM-Case1 空间波束预测 | BM-Case2 时间波束预测 | CSI预测 | |---|---|---|---| | RAN1特性组 | R1 58-1-2 | R1 58-1-4 | R1 58-3-1 / 58-3-2 | | 模型位置 | UE侧单边 | UE侧单边 | UE侧单边 | | 输入 | Set B实测4/8/16根 | 历史K=2/4/8次测量 | CSI-RS快照（N4=1或多张） | | 输出 | Set A 8/16/32/64根中最优1~4根 | 未来1~8个时刻最优波束 | 未来信道状态 | | 关键参数 | subset/diffSet/both | timeGap 10~160ms | scalingFactor n1/n2/n4 | | 推理时限 | ≤4 ms | ≤7 ms | ≤8 ms（倍增梯子） | | 报告类型 | 周期/非周期/半持续 | 周期/非周期/半持续 | 仅非周期/半持续 | | CPU占用 | 0~8，池1~2 | 0~8，池1~2 | 0~8，池1~2 | | 典型收益 | 测量开销砍至6.25% | 高速场景波束切换前瞻~1.28s | 抗信道老化、省上行开销 | ## 十、给网优工程师的落地清单 把全文收拢成下次厂商交流会上可以照着问的五个问题： 1. **问特性组编号，不问话术。**“58-1-2和58-1-4支持吗”是有标准答案、能写进能力表的问题；“支持AI/ML吗”从来没有产生过有用的回答。 2. **问模型错了会怎样。**不要问“精度多少”（谁的分布上的精度？），要问：预测波束错误时UE做什么、多久恢复、在我的哪些计数器里长什么样。答不上来，说明监测是事后补的。 3. **问CPU声明值，然后上仪表验证。**零是合法的，零甚至可能是真的。但一台声明零占用、推理高负载下却悄悄劣化普通CSI报告的终端，没有违反规范——它只是对自己认识不足。 4. **问timeGap推荐值及依据。**这是最好的筛选题：规范里没有正确答案，正确答案只能来自实测。如果对方给出一个不涉及移动性分布的单一数字，说明他们没在现网部署过。 5. **问规范版本。**"Rel-19 compliant"对应哪个版本、何时冻结？让对方报出版本号，然后自己对那份文档做一次`aiml-`检索——十分钟的事，比任何博客（包括本文）都可靠。 往前看，下一步显然是网络侧模型——跑在gNB里、O-RAN RIC的xApp/rApp里，看得见全网所有UE，是另一套约束、也更混乱的部署故事。而按3GPP 2026年6月批准的Rel-21时间表，6G首版标准功能冻结定在2028年12月——AI原生化的大戏在那一版，但地基已经由Rel-19打好：怎么采数据、怎么声明适用性、推理占多少预算、限时多少、失灵了怎么对账。这不是头条，是地基。看过太多头条技术死在现网手里的人，会选地基。 ## 参考来源 1. [What 3GPP Actually Standardised for AI in the Air Interface — A Release 19 Teardown](https://www.cafetele.com/articles/article-3gpp-ai-air-interface-rel19.html) — CafeTele对TS 38.331 Rel-19全部27个`aiml-*`标识符的逐条拆解，本文信令细节与ASN.1引用的主要来源 2. [3GPP Release 19 and beyond — AI at the physical layer](https://www.rcrwireless.com/20251002/fundamentals/ai-release-19) — RCR Wireless对Rel-19 AI/ML框架五大用例与产业影响的综述 3. [WI #1020093 - NR_AIML_air](https://portal.3gpp.org/desktopmodules/WorkItem/WorkItemDetails.aspx?workitemId=1020093) / [WI #1021093 - NR_AIML_air-Core](https://portal.3gpp.org/desktopmodules/WorkItem/WorkItemDetails.aspx?workitemId=1021093) — 3GPP官方工作项页 4. [AI/ML for NR Air Interface](https://www.3gpp.org/technologies/ai-ml-nr) — 3GPP官方技术文章；及[3GPP官网](https://www.3gpp.org/newsevents/3gpp-news)Rel-21时间表（6G功能冻结2028年12月） 5. [AI-RAN Performance Benchmarks 2026](https://7g.network/reports/ai-ran-benchmark-2026/) — DT柏林诺基亚AirFrame AI试验数据（11%吞吐/25%节能，据该报告，未经官方完整证实） 6. [Nokia maps out AI RAN vision at MWC ahead of 6G era](https://www.datacenterdynamics.com/en/news/nokia-maps-out-ai-ran-vision-at-mwc-ahead-of-6g-era/) — Data Center Dynamics，2026年3月 --- > 本文由「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 等场景全覆盖。